Minutes IETF97: lwig
Light-Weight Implementation Guidance
||Minutes IETF97: lwig
11:10-12:10 Thursday Morning session II
Grand Ballroom 3
Minutes Taker: [Rahul] [Mohit]
Jabber Scribe: [Jing]
[Zhen] presenting the milestones
1. Agenda bashing 5 min
2. TCP over Constrained Nodes Carles Gomez Montenegro
draft-gomez-lwig-tcp-constrained-node-networks 20 min
[Carles] presenting history of draft, updated after ML comments
presenting motivation of the draft.
TCP is neglescted/critised for IoT ... but may have to be used in several
scenarios new characteristic update about link layer of low trans rate <
1Mbps Primary scenario been considered is for constrained networks working with
cloud infrastructure. Traversal of middlebox is considered Typicall TCP conn
will be initiated by constrained device ... recommendation regarding setting
the TCP MSS.. align it with IPv6 MTU
Updates to recommendations in window size ... earlier it was one in-flight
segment but now it can be increased to say 5-MSS Recommend to use alternate RTO
estimation mechanism as compared to CoCoA ... evidence of CoCoA works better as
compared to RFC 6298. explains some conflicts of CoCoA mechnaisms with RFC 6298
explains problems of TCP connection lifetimes with the middleboxes ..
New ideas of using TCP fast open for short TCP connection lifetime
Compare TCP fast open with cookie or open new conn every time new data is to be
sent (?) .. Explains SACK mechanism for constrained devices
Talks about delayed-Acks from TCP receiver..
Explains UIP characteristics for constrained devices
[Rahul] UIP uses buffers for TCP outgoing packets as well ..
[Michael Scharf] why the document remommends a lot of aspects not followed by
LWIP stack [Carles] Possible excercise for future version ... depending on
class of the device it may be useful to classify the implementation.
[Suresh]: Have you run it by TCPM people after the latest draft published ? Pls
take into consideration michael's comment Still have to address .. need to take
into the account some c
[thomas]: explains latest update of RIOT-TCP.. expect riot-TCP early next year
[Yoshoifumi]: Michaels comment is valid but how to keep it continuously
[Suresh]: if the doc is adopted here, it will be better to run the LC on both
the WG .... make sense to keep both the WGs such as TCPM and LWIG for this
draft [Zhen]: LC can be handled as per suresh suggestion [Zhen]: how many
people of read any verion? Answer: 10 [Zhen]: how many would want to keep
reviewing? Answer: 5
3. Implementation experiences of public-key cryptography on 8-bit
micro-controllers Mohit Sethi
https://tools.ietf.org/html/draft-ietf-lwig-crypto- sensors-01 15 min Explains
the goal... how hard is it to do pub key crypto on constrained devices ? What
kind of perf can be expected from open source libs? Performance of RSA ...
small key size is reasonable for certain scenarios ... for larger key size perf
undesirable .. Execution time of RSA 2048 key size is unusable
For one of the curve, implementation was changed to assembly code and could
reduce the perf drastically ... thus getting reasonable perf
New libraries for EdDSA available now .. explains the numbers .. explains the
reasoning behind such large numbers for key signing for certain use-cases..
Perf numbers for sample app witht the sample setup explained..
Explains that if 8b uproc is able to achieve this perf then the 32b uproc might
be able to do lot better.. Message freshness ... how it can be verified in the
Tradeoffs for doing crypto at link/network/transport/app
Big change of removing the reference of group keys.
Smaller key lengths in the draft are for reference purpose only ..
[Carsten]: one of the interesting happening is ... much lower power radio .. it
would be nice to have current numbers .. old wisdom was it was always better to
avoid sending the pkts ... it would be nice to have the numbers... conventional
wisdom is been challenged by newer chips ... [Mohit]: any specific radio to
investigate ? [Carsten]: I can lookup and get back ....
We ll ask again on ML for WGLC ..
4. Neighbor Management Policy and Implementation Consideration for 6LowPAN -
Rahul A. Jadhav
no draft but relevant topic 15 min
Discussion on ROLL mailing list about this
How is it handled currently in open source implementations and what we did in
one of our practical deployments Network sizes can be huge LRU in Contiki: you
would get downtime RIOT: First come first serve In continki it is not possible
to have the node density
How do you compare link quality amond neighbors
Neighbor table updates happens in several cases
Reservation for direct childs and Pre auth nodes
[Michael Richardson]: We should have draft on this
Can keep child of direct child also above if direct child is removed
You can know when the Auth is done in PANA. Also in other auth
[Zhen]: Eviction of direct child? BR is supposed to have larger memory.
>>>> Rahul: My BR has same computation capabilities as any other
[Mohit]: We need a draft on this