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.