# 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 Thomas Watteyne 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