Minutes IETF97: lwig
minutes-97-lwig-00

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 ..

explains LWIP

[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
draft ...

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 ....

Thanks
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 node

 [Mohit]: We need a draft on this