Minutes IETF100: 6tisch
minutes-100-6tisch-00

# Minutes, IETF 100 6TiSCH WG Meeting #

Note: these minutes are formatted using Markdown.

Agenda and Meeting Information
==============================

```
Meeting        :   IETF 100, Monday, November 13, 2017 (+08)
Time           :   15:50-17:20 SGT, Monday Afternoon session II (90min)
Location       :   Bras Basah, Raffles City Convention Center, Singapore
Chairs         :   Pascal Thubert <pthubert@cisco.com>
                   Thomas Watteyne <thomas.watteyne@inria.fr>
Responsible AD :   Suresh Krishnan
URLs           :   http://tools.ietf.org/wg/6tisch/
                   https://datatracker.ietf.org/wg/6tisch/
                   https://www.ietf.org/mailman/listinfo/6tisch
                   https://bitbucket.org/6tisch

 Intro and Status
    * Note-Well, Blue Sheets, Scribes, Agenda Bashing           [ 5min]
    * Status of the work                                        [ 5min]
      (chairs)

 Chartered items
    * draft-ietf-6tisch-6top-protocol                           [10min]
      (Xavi Vilajosana)

    * draft-ietf-6tisch-minimal-security                        [15min]
      (Malisa Vucinic)

    * draft-ietf-6tisch-dtsecurity-zerotouch-join               [10min]
      (Michael Richardson)

    * draft-ietf-6tisch-6top-sfx                                [ 5min]
      (Diego Dujovne)

 Unchartered items, time permitting
    * draft-chang-6tisch-msf                                    [15min]
      (Tengfei Chang)

    * draft-satish-6tisch-6top-sf1                              [10min]
      (Bing Liu - Remy)

    * draft-richardson-6tisch-roll-join-priority                [ 5min]
      (Michael Richardson)

 Any Other Business, IEEE status
    * QS
```

Resources
=========

* agenda: https://datatracker.ietf.org/meeting/100/materials/agenda-100-6tisch/
* meeting material: https://datatracker.ietf.org/meeting/100/materials.html

Summary
=======

_(This summary is also posted in the INT area wiki,
https://trac.ietf.org/trac/int/wiki/IETF100)_

```
The 6TiSCH working group has a stable set of "6TiSCH Minimal" specifications:
- `6tisch-minimal` (RFC8180)
- `draft-ietf-6tisch-minimal-security`
- `draft-chang-6tisch-msf`

This forms a complete protocol stack, which can be implemented and benchmarked.
Ongoing work in the WG focuses on augmenting this "Minimal" solution with:
- additional Scheduling Functions
- zero-touch security
- optimizations related to routing and beaconing

7 drafts were presented t IETF 100, both related to the 6TiSCH Minimal specs
and its extensions

- `draft-ietf-6tisch-6top-protocol` transitioned to AD Evaluation status.
    The draft is stable and has been implemented and tested.
    The WG is waiting for reviews, in particular from the IoT-dir
- `draft-ietf-6tisch-minimal-security` is, pending the description of DSCP
bits, ready for WGLC.
    The WG believes that the next revision will be ready for WGLC.
- `draft-ietf-6tisch-dtsecurity-zerotouch-join`: the work is progressing fast.
    The WG acknowledged the good progression of the work.
- `draft-ietf-6tisch-6top-sfx`: some editorial changes are needed because this
(experimental) draft can go into WGLC.
    The chairs believe the WGLC period will be opening before IETF101.
- `draft-chang-6tisch-msf`: this specification is part of the Minimal 6TiSCH
solution.
    2 implementations already exist.
    The chairs are confident this solution will be stable before IETF101.
- `draft-satish-6tisch-6top-sf1`: the draft is important for the WG, but
several key points lack specifics.
    The chairs recommended for the authors to continue the work.
- `draft-richardson-6tisch-roll-join-priority` was not presented due to lack of
time. ```

Volunteers
==========

* notetaker 1:   **Dominique Barthel**
* notetaker 2:   **Federico Sismondi**
* Jabber scribe: **Ines Robles**

Action items
============

* **Rahul** to send pointer of LWIG draft to 6TiSCH ML.
* **Malisa** to update minimal-security draft and ask for WGLC afterwards.
    * TOS bits change
* **Diego** to update SFX draft:
    * no more mentions of SF0
* **Tengfei** to update MSF:
    * "NumCellsElapsed" rather than "NumCellsUsed"
    * when inconsistency detected the 6P CLEAR req and response shound be
    exchanged in the minimal cell * limit backoff exponent on dedicated cells
    as only 2 nodes discussing
* **Thomas** to provide feedback about draft-satish-6tisch-6top-sf1 on 6TiSCH
ML.

Minutes
=======

* _[15.52]_ (exp. 15.50) Start of meeting
* _[15.52]_ (exp. 15.50) Intro and Status
    * Note-Well, Blue Sheets, Scribes, Agenda Bashing
    * Status of the work
    * [**Thomas**]
        * "Minimal 6TiSCH" solution ready
        * now, two focus points:
            * outside of IETF: facilitating market adoption through
            benchmarking, providing open-source implementations, interop
            testing and conformance tools, etc. * inside of IETF: build new
            technologies. We need to think about rules for adopting further
            work, so it fits well and extends what exists.
    * [**Pascal**] DIO and Fast ReRoute work to be done in ROLL, we'll be
    asking for it. EB at IEEE, etc. First define the need, here.
* _[16.00]_ (exp. 16.00) draft-ietf-6tisch-6top-protocol (**Xavi Vilajosana**)
    * status:
        * stable , v-9
        * all proposed cells in the list are equivalent, no priority meaning
        attached to order. * inconsistency: use of a Sequence Number to detect
        it. Many situations would lead to inconsistencies, some examples
        provided. * clarified use of Error Codes. Listed them all in a Table.
    * [**Thomas**]
        * answers discussion in Prague, document seems stable, already two
        implementations, one more coming
    * [**Suresh**]
        * next step is to receive review from IoT Directorate
* _[16.09]_ (exp. 16.10) draft-ietf-6tisch-minimal-security (**Malisa Vucinic**)
    * -04 published in october.
    * fully relies on PSK, zero-touch draft deals with certificates
    * Update #1: Key/Nonce derivation
        * changes induced by changes in OSCORE. Nonces constructed differently.
        Explained on slide 4 and following. * Join request defined from what's
        been standardized by OSCORE * Join request/response use now same
        nonces, again, changes come from what's been defined by OSCORE
    * Update #2: Error handling: opened DoS attack opportunity.
        * solution from -04: use non-confirmable CoAP msg for join request. In
        case of an error, JRC doesn't reply. No DoS attacks, but forces pledge
        to implement retransmission at the app layer.
    * [**Thomas**] clarifying question: pledge sends a Join Request, if
    anything wrong, won't get back any response. Only Join Response if
    everything correct. * [**Malisa**] yes. * [**Michael**] through Meetecho
    chat
        * `@Thomas`: if it's the wrong network, then you have to timeout. But
        you had to do that anyway, because you can't trust the negative reply
        anyway.
    * [**Thomas**] through Meetecho chat
        * `@Michael`, agreed
    * update #3: Join Request Retransmissions. Retransmission counter, timeout
    doubled at each attempt (similar to RFC7252). * [**Michael**] through
    Meetecho chat
        * `@Thomas`, previously the reliability came from the "TCP" layer
        (which is actually CoAP), now it comes from the application
    * [**Thomas**] through Meetecho chat
        * yep, understood
    * [**Pascal**] new way to improve SF, with several traffic classes, respond
    differently to each class. * [**Rahul**] slide 9 neighbor cache increase.
    Please see LWIG draft which describes this. Will send pointer on the ML. *
    [**Pascal**] will next version be ready for last call? * [**Malisa**] will
    be writing soon a new version, and go from there to WG last call *
    [**Pascal**] about dependence on normative work OSCORE? * [**Goran**]
    OSCORE not is WGLC yet * [**Michael**] through Meetecho chat
        * `@Goran`, but MISSREF will sort out the timing, if the documents are
        done.
    * [**Suresh**] difficult to synchronise these two drats. Cannot do
    cross-area synch. * [**Michael**] through Meetecho chat
        * Suresh, but zerotouch-join still uses certificates, and could depend
        upon EDHOC.
    * [**Thomas**] should the TOS bits change be done in minimal-security
    draft, of a new draft? * [**Pascal**] same draft. Just indicate which
    classes the Join traffic should be part of.
* _[16.34]_ (exp. 16.25) draft-ietf-6tisch-dtsecurity-zerotouch-join (**Michael
Richardson**)
    * -01 version syncs with ANIMA BRSKI -09
    * can be read standalone
    * voucher uses YANG/CBOR, hoping -core-sid to progress.
    * [**Goran**] what's going on right now is a comparison between DTLS and
    EDHOC handshake, we are going to have a interim with a proposal about the
    comparison between EDHOC handshake and the other mechanism * DTLS has DDoS
    mitigation mechanism that involves another round-trip, to decide whether we
    turn this on. * dependencies to CORE (SID), ACE (EST over CoAP), to 6TiSCH
    as well (outsourced work). * looking for additional co-authors and
    reviewers * [**Peter**] will have meeting, discuss EST/CoAP, decision to
    put in separate doc, will keep you updated.
* _[16.42]_ (exp. 16.35) draft-ietf-6tisch-6top-sfx (**Diego Dujovne**)
    * status: was on-the-fly scheduling and scheduling function zero (SF0)
    * on-the-fly experimental results
    * [**Pascal**] make sure to clean out draft for mentions of SF0.
    * analyzed allocation stability: added feature in SFX compared to SF0.
    * review in May and associated comments submitted in sf-05. More comments?
    Ready for WGLC? * [**Thomas**] I have some editorial comments we have to go
    through. Should be done before considering WGLC. * [**Thomas**] changing
    mind on SF nomenclature. No longer use numbers, would be getting ahead of
    IANA work. * [**Lijo**] through Meetecho chat:
        * do you have some experimental results?
* _[16.50]_ (exp. 16.40) draft-chang-6tisch-msf (**Tengfei Chang**)
    * Minimal SF (aka MSF). Uses 6TiSCH-minimal RFC.
    * organizes the use of minimal (shared) cell.
    * describes node behavior at Boot (minimal-security compliant)
    * describes 7 steps at boot
    * dynamic scheduling , explains reasons for for adding removing cells
        * adapt to traffic: maintain 2 counters, NumCellsUsed and NumCellsPassed
            * [**Thomas**]: recommendation to rename latter to NumCellsElapsed
    * running code:
        * implemented in 6TiSCH simulation
        * implemented in OpenWSN
        * works! more results coming
    * [**Pascal**] will be a need to identify Class for Join traffic.
    * [**Pascal**] describe the values used on per classed basis (4,12,16).
    * [**Simon**] through Meetecho chat
        * is the dedicate cell both TX and RX?
    * [**Tengfei**] yes
    * lessons learned from implementation:
        * when inconsistency detected the 6P CLEAR req and response shound be
        exchanged in the minimal cell * limit backoff exponent on dedicated
        cells as only 2 nodes discussing
    * [**Charlie**] what causes the scheduling inconsistency?
    * [**Thomas**] will take this offline.
    * [**Thomas**] congrats to you and Malisa to implemt this in two weeks!
    * Additional discussion on Meetecho chat
        * [**Diego**] would it be nice to see traffic burst conditions on the
        experiments * [**Malisa**] we did this in the simulator. Results on the
        simulation result slide * [**Diego**] yeap, but the experiments are the
        ones which suffer real conditions * [**Malisa**] how the algorithm
        converges can also be seen in the simulation * [**Diego**] in fact, the
        code is different between 6tisch simulator and openwsn * [**Malisa**]
        and also how it adapts to the bursty traffic[17:12] * [**Xavi**] I
        think that the simulation can bring more information as we can reach
        the limits * [**Malisa**] could be, we implemented independently *
        [**Xavi**] the real conditions are really constrained by the setting *
        [**Malisa**] this is still preliminary * [**Diego**] exactly. but the
        platform can be used to generate more realistic conditions *
        [**Malisa**] realistic in what sense? link-layer drops? traffic
        pattern? * [**Diego**] traffic pattern generation, phy-layer
        interference * [**Malisa**] I agree we can't have completely realistic
        behavior on the link but we do introduce drops probabilistically in the
        simulator. However, I don't see any difference in how you generate
        traffic between the simulator or a real app. * [**Diego**] when you
        generate real traffic, it goes through the stack on every node and
        suffers processor limitations, plus other resource clogs which are not
        seen on the simulator * [**Malisa**] if a node transmits periodically
        with a period on the order of 15s, I am not sure how much does
        processing delay on the order of ms affect the traffic pattern in the
        network.
* _[17.10]_ (exp. 16.55) draft-satish-6tisch-6top-sf1 (**Bing Liu - Remy**)
    * SF1: reserve track to destination multiple hops away
    * describes end to end operation (slide 3)
    * describes PATH and RESV messages (slide 4)
    * 3 step transaction for one-hop operation, notes that could be done in 2
    steps * presents state transition diagram for downstream node * next steps:
    complete definition, cover error handling, SF behaviour when node boots,
    security and examples * [**Thomas**] I have a some comments but let's
    discuss it later as running out of time..
* draft-richardson-6tisch-roll-join-priority (**Michael Richardson**)
    * skipped because of lack of time
* _[17.19]_ (exp. 17.10) Any Other Business
    * no other business raised in room
* _[17.20]_ (exp. 17.20) End of Meeting