## DRAFT ## # Minutes, 26 January 2018 interim, 6TiSCH WG # Connection details ------------------ * Date: January 26th, 2018 7-8am Pacific http://www.worldtimebuddy.com/?qm=1&lid=100,12,5392171,1850147&h=100&date=2018-01-26&sln=14-15 * Material link: https://datatracker.ietf.org/meeting/interim-2018-6tisch-01/session/6tisch * Meeting link: https://cisco.webex.com/ciscosales/j.php?MTID=m26a052c1fa38de0d29a17b7228b2b9f2 * Meeting number (access code): 204 172 595 * Meeting password: fcqY7cPj (32797275 from phones) Present ------- 1. Xavi Vilajosana 1. Thomas Watteyne 1. Pascal Thubert 1. Diego Dujovne 1. Fabrice Theoleyre 1. Georgios Papadopoulos 1. Jonathan Munoz 1. Lotte Steenbrink 1. Mitsuru Kanda 1. Remous-Aris Koutsiamanis 1. Tengfei Chang 1. Yasuyuki Tanaka 1. Simon Duquennoy 1. Remy Liu 1. Rahul Jadhav 1. Carsten Boorman Taking notes _(using Etherpad)_ ------------------------------- 1. Xavier Vilajosana 1. Pascal Thubert Action Items ------------ * Xavi to review draft-papadopoulos-6tisch-pre-reqs Agenda ------ * admin [ 2min] * draft-papadopoulos-6tisch-pre-reqs [20min] * security update (Michael Richardson) [ 5min] * 6LoWPAN Fragmentation (Thomas Watteyne) [25min] * Any Other Business [ 3min] Minutes ------- * [07:05] Meeting starts * [07:07] Admin update * agenda and last meeting minutes are approved. * IETF101 in london * 90 min meeting * 05/03/18 cutoff date *- 12/03/18 final agenda * [07:10] draft-papadopoulos-6tisch-pre-reqs * Georgios Papadopoulos presents * Presents about packet replication and elimination in 6tisch * idea is to increase the reliability in a 6tisch network. Also influence or improve jitter * suggest PRE (packet Replication and Elimination) can help on jirtter and delivery ratio * Overhearing, replication and elimination are the tools used to address the objectives * Need a cell with more than one receiver for replication * replication-> each 6tisch node transmit the packet to its preferred parent and a copy to another selected parent. * Requirement is to define an alternate parent. This potentially requires the extension of the DIO so this information is signaled and node can know other information to select an alternative parent. * TW: What information is sent through this DIO modification? * G.P: the DIO contains information so one node cannot that there is a common ancestor through their paths. * need cells to allow multiple receivers * packet elimination through tagging. * [07:35] Security Update * Pascal and Thomas present on behalf of Michael and Malisa * minimal security Status: resolved the issue on join traffic tagging. Not published yet * [07:40] Fragmentation update. Thomas Watteyne, chair of the Design Team, presents. * happened at 6lo * Gabriel and Samita asked to create a fragmentation design team. * the design team is chaired by Thomas W. Carsten, Pascal, Gabriel are part of it. * problem is that fragmentation requires per-hop reassembly. * RFC4944 defines a fragment header. Packets are re-assembled and possibly fragmented again. * there is a reassembly timer that expires if a hop do not receive all fragments. * per hop-fragmentation and reassembly, this increases latency as the packet progresses as the speed of the last fragment. * Reliability is another problem as when fragments are lost keep the memory occupied for some time. If there are other nodes transmitting and nodes have memory limitation packets are dropped. * When a fragment is lost all the packet is dropped and needs to restart again. * -solution is fragment forwarding. * Carsten's book, introduced the concept of virtual buffers, which mainly imply that the address and header is kept in the node but the fragment is actually forwarded immediately as it is received. * new draft from carsten has been published at LWIG.Thomas is working on integrating with some of his contributions. * Outcomes of the Frag. DT|. * 2 documents will be produced. * informational document describing how fragmentation works. Discusses its limits. * std track, builds on top of the first one. adds fragment recovery * Xavi: Clarifying question: is ack per fragment * Thomas: a bitmap indicates all the fragments and is transmitted by the the destination. So this is end to end group ack once all fragments have been received or a timeout has expired.