Minutes interim-2018-6tisch-01: Fri 16:00

Meeting Minutes IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch) WG
Title Minutes interim-2018-6tisch-01: Fri 16:00
State Active
Other versions plain text
Last updated 2018-01-26

Meeting Minutes

   ## DRAFT ##

# Minutes, 26 January 2018 interim, 6TiSCH WG #

Connection details

* Date: January 26th, 2018  7-8am Pacific
* Material link:
https://datatracker.ietf.org/meeting/interim-2018-6tisch-01/session/6tisch *
Meeting link:
    * Meeting number (access code): 204 172 595
    * Meeting password: fcqY7cPj (32797275 from phones)


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


* admin                                          [ 2min]
* draft-papadopoulos-6tisch-pre-reqs             [20min]
* security update (Michael Richardson)           [ 5min]
* 6LoWPAN Fragmentation (Thomas Watteyne)        [25min]
* Any Other Business                             [ 3min]


* [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,

    * 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

    * 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

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