Minutes IETF98: lwig
minutes-98-lwig-01

Note taker: Mohit Sethi

Monday 17:10-18:10
March 27, 2017
Zurich D

Onsite chair: Suresh Krishnan (sitting in AD), Jing Zuo (Vonlunteer)
Online co-chair: Zhen Cao

1. Agenda bashing 5 min

2. TCP over Constrained Nodes    Carles Gomez Montenegro
https://tools.ietf.org/html/draft-gomez-lwig-tcp-constrained-node-networks 15
min

Carles: Presented in IETF 96. Has undergone updates. Several application
protocols being used. XMPP, HTTP/1.1 and HTTP/2 and non-IETF application
protocol such as MQTT. TCP has been widely neglected for IoT scenarios. Status
is now informational. How TCP can be configured for the scenarios we are
considering. We have added explicit definition of CNNs. Updated section on
Maximum segment size. 6lo links define an MTU of 1280 bytes. MSS has to set
accordingly. TCP MSS maybe set to bigger values but we have to be careful.
CoCoA added as side note.

Section on window size of TCP. Earlier recommending single -MSS window.
Modified. RTO estimation updated. Added text to security considerations.
Security comes with increased overhead and complexity. Annex in document. 
Section on RIOT and OpenWSN are empty. Call to working group for work.

Rahul: Are you considering all TCP options and checking if it is suitable for
constrained networks. Along with each option there is security. TCP Fast open
should or should not be used in constrained networks. Mohit: Should you or
should you not implement the security options. Kerry: MSTP draft that you
referenced earlier. Found out late that if > 1280 then it should do path MTU.
You should probably stick with the number. Robby: Glad to see work. Have you
considered about congesation control algorithms. There is stuff out there that
is more applicable. Carles: Not yet. Michael: Thanks a lot for this work.
Moving in good direction. Come to TCPM if there will be any TCP modification
consideration. Erik: Confirming that you have to path MTU discovery if > 1280.
Do you want to go down that path? There is strong assumption. Carles: We will
take this into consideration.

Authors ask if it is good moment to ask if good time for working group adoption.

Suresh: Michael will take care about draft. Do you want to the list or hum.
Read: 7.
Suresh: Take it on the list.

3. Neighbor Management Policy and Implementation Consideration for 6LowPAN  -
Rahul A. Jadhav
https://tools.ietf.org/html/draft-jadhav-lwig-nbr-mgmt-policy-00   20-min

Suresh: New slides will be uploaded.

Rahul: Signalling considerations. Why is neighbor management is required. It is
difficult to anticipate size of neighbor cache. Prioritization does not always
work. Cannot evict. Can have ripple affect. There are implications on which
entry can be removed. Most opens source implement policies which are not
optimal. The routing adjacencies should not change.

This guideline should be protocol agnostic as far as possible. PANA as key
management and RPL as example protocols. Holistic approach to neighbor
management. PANA relay agent discovery. Implicit vs explicit signalling. Don't
want to add overhead in terms of neighbor discovery.

IPv6 ND.

Mohit: How does this relates to 6lo work on new low-power neighbor disovery.

Rahul: Not adding new signalling. Using exisitng specification. Recommending
some things.

Draft does not specify link-estimation. All implementation have to consider
some sort of enforcement policy. Draft has a sample policy. Graceful rejection.
If you send a DAO and table is full. In PANA negative signalling is not
available.How does child know that parent node is full. Might be possible to
solve this based on proactive signalling. Feedback of working group needed.
Call for adoption

Samita 6lo co-chair: In this document you have multiple solutions put together.
RPL or pure NDP or PANA. I am not 100% clear about charter of LWIG if it this
could be divided into different pieces. I don't think you can implement it
without changing 6lowpan. Present it in respective groups.

Rahul: Only implementaiton guidelines. Any extensions go elsewhere. This is
informational.

Meeting adjorn.