* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

6tisch Status Pages

IPv6 over the TSCH mode of IEEE 802.15.4e (Active WG)
Int Area: Suresh Krishnan, Terry Manderson | 2013-Oct-08 —  

IETF-103 6tisch minutes

Session 2018-11-08 1610-1810: Boromphimarn 3 - Audio stream - 6tisch chatroom


minutes-103-6tisch-00 minute

          # Minutes, IETF 103 6TiSCH WG Meeting #
          Note: these minutes are formatted using Markdown.
          Agenda and Meeting Information
          Meeting        :   IETF 103 Thursday 8 November 2018
          Time           :   16:10-18:10 Thursday Afternoon session II (120min)
          Location       :   Boromphimarn 3, Bangkok Marriott Marquis Queen's
          Park Hotel
          Agenda         :
          Meeting Slides :   https://datatracker.ietf.org/meeting/103/materials.html
          Etherpad       :
          Meetecho       :   http://www.meetecho.com/ietf103/6tisch/
          Audio stream   :   http://ietf103streaming.dnsalias.net/ietf/ietf1032.m3u
          Chairs         :   Pascal Thubert
                             Thomas Watteyne
          Responsible AD :   Suresh Krishnan
          WG URLs        :   http://tools.ietf.org/wg/6tisch/
           Intro and Status (chairs)
              * Note-Well, Blue Sheets, Scribes, Agenda Bashing           [10min]
              * Status of the work, link with other WGs
           Chartered items
              * draft-ietf-6tisch-architecture                            [10min]
                (Pascal Thubert)
                goal: prepare WGLC
              * rfc8480                                                    [5min]
                (Xavi Vilajosana, remote)
                goal: status on publication
              * draft-ietf-6tisch-msf
                  * intro update (Simon Duquennoy)                         [5min]
                  * simulation campaign (Yasuyuki Tanaka, remote)         [15min]
                  * experimental campaign (Tengfei Chang, remote)         [15min]
                goal: discuss ongoing optimizations
              * draft-ietf-6tisch-minimal-security                        [25min]
                (Malisa Vucinic)
                goal: resolution of WGLC comments
           Unchartered items, time permitting
              * draft-tiloca-6tisch-robust-scheduling                     [15min]
                (Simon Duquennoy)
                goal: gathering WG interest and feedback
              * status of the 6lo fragmentation design team (Thomas)       [5min]
              * AOB                                                          [QS]
           Total scheduled time                                        105/120min
          * notetaker 1: **Dominique Barthel**
          * notetaker 2: **Georgios Papadopoulos**
          * Jabber scribe: **Malisa Vucinic**
          Action items
          * editors of MSF (**Tengfei**) and minimal-security (**Malisa**) to read
          this doc and make sure it represents their draft well.
          * **Pascal** to merge terminology draft into architecture. Keep
          * **Thomas** to shepherd architecture draft.
          * **Tengfei** to raise suggestions found with MSF on the ML, ensure get
          into MSF.
          * **Pascal** to organize an interim about MSF.
          * **Malisa** to discuss final changes to the minimal-security draft
          (no netid configuration of the JRC, configuration of the cap) on the ML
          * **Chairs** to open 1-week WGLC on changes in -09.
          (This summary is also posted in the INT area wiki,
          During IETF103, the 6TiSCH WG has 1 WG meeting and 2 side meetings.
          The WG meeting covered 5 drafts:
          * `draft-ietf-6tisch-architecture` is almost ready. Pascal pushed -16
          before the meeting. Pascal will merge `draft-ietf-6tisch-terminology`
          into `draft-ietf-6tisch-architecture` and publish -17. WGLC will be
          called and authors of the key 6TiSCH draft will be asked to review.
          * `rfc8480` was published.
          * `draft-ietf-6tisch-msf` was covered through 3 presentations: an
          intro and two "lessons learnt" presentations by 2 implementors (one
          by simulation using the 6TiSCH simulator, one by experimentation
          using OpenWSN). Performance is very good and matches the
          expectations, some lessons learnt already captured in Appendix E of
          `draft-ietf-6tisch-msf`. Authors will update the document based on these
          lessons learnt and ensure with implementors that all lessons learnt have
          been captured.
          * `draft-ietf-6tisch-minimal-security` is almost ready. It received 7
          reviews during the last WGLC, all of which have been integrated, and
          which reviewers approve. Two final changes are still needed. Editor will
          discuss those on the ML, integrate them into a new version of the draft
          if consensus. Chairs will then open a 1-week WGLC only on those changes.
          * `draft-tiloca-6tisch-robust-scheduling` is new out-of-charter work
          which proposes a "cell shuffling" solution to prevent a selective jamming
          attack. The presentation was well received, the author are asked to
          provide more arguments about the importance of such attack.
          The first side meeting was bar BoF "Predictable and Available
          Wireless", organized by Pascal Thubert, in which we discusses the
          opportunity to apply 6TiSCH to other physical layers, in particular
          802.11 WiFi. Discussions are continuing on a new mailing list
          The second side meeting was called to discuss EDHOC
          (draft-selander-ace-cose-ecdhe) and was attended by Jim Schaad (ace
          co-chair), Roman Danyliw (ace and secdispatch co-chair), Goran Selander,
          Francesca Palombini (EDHOC authors), Malisa Vucinic (6TiSCH security),
          Pascal Thubert and Thomas Watteyne (6TiSCH co-chairs). It was agreed
          that draft-selander-ace-cose-ecdhe would go through the secdispatch
          process to find the right home for it. The 6TiSCH WG agreed to produce a
          requirements document in end-of-year, and present that to a secdispatch
          interim meeting which will be held in January 2019.
          * [16.11, expected 16.10] Meeting starts
          * [16.11, expected 16.10] Intro and Status (chairs) [10min]
              * Note Well, notetakers, jabber scribe, blue sheets.
              * security slides just added to the repo.
              * **Thomas** goes through agenda. Any suggestions fro change? none
              heard, agenda adopted.
              * **Pascal** gives the updates from IETF 102 meeting, on RFC8480,
              * ODVA looking at 6TiSCH for their low data rate Common Industrial
              * Thread looking at expanding from home to building automation.
              * There is a discussion and thoughts whether Thread could be converged
              with 6TiSCH
              * related work done in other WGs: 6lo, ROLL, CoRE.
          * [16.21, expected 16.20] draft-ietf-6tisch-architecture (**Pascal
          Thubert**) [10min]
              * kept up-to-date during the work at 6TiSCH. Question to publish it
              now that the work is completing.
              * structured into two big sections: high level architectue and finer
              details of 6TiSCH components
              * version 16 is published
              * **Pascal** proposes to go for WGLC for this draft, so that we do
              MSF now and then security.
              * **Thomas** suggest to wait for MSF and minimal security?
              * **Pascal** this one is ready, why wait? We know enough of MSF and
              minimal security for the purpose of this architecture document.
              * **Georgios** if new work is started after this is published,
              how will it get integrated?
              * **Pascal** this "story" is complete, we can close this document. If
              we start a new story later, we'll write about it.
              > **Action item**: editors of MSF (**Tengfei**) and minimal-security
              (**Malisa**) to read this doc and make sure it represents their
              draft well.
              * **Thomas** what about terminology? Do we push it together with
              this one?
              * **Pascal** yes, we'll publish terminology at the same time.
              * **Suresh**: many documents. Could we put terminology is this arch
              draft? Would this make sense?
              * **Pascal** This archi is very similar to the one from detnet,
              this document should in the standard track (Pascal changed it to
              standard track already)
              * **Suresh** is fine if stays standards track.
              * **Suresh** will you shepherd this doc, Thomas?
              * **Thomas** yes.
              * **Thomas** both docs are wrappers, one would read them both at
              the same time.
              > **Action item**: **Pascal** to merge terminology draft into
              architecture. Keep standards-track.
              * **Pascal** Thomas is on the author list. Cannot be shepherd.
              * **Suresh** Thomas is not an editor, I don't have an issue with
              Thomas being the shepherd.
              > **Action item**: **Thomas** to shepherd architecture draft.
          * [16.32, expected 16.30] rfc8480 (**Xavi Vilajosana**, remotely) [5min]
              * was published as RFC8480 on 5-Nov-2018.
              * Minor changes from the previous version.
              * Important clarification comment in Section 3.4.7 (see the details
              in slide 2)
              > No further questions from the room.
          * [16.35, expected 16.35] draft-ietf-6tisch-msf, intro update (**Simon
          Duquennoy**, remotely) [5min]
              * Simon is presenting the updates of this draft since IETF 102. No
              new content but fixing issues.
              * Many of the issues were raised from implementation by Yatch and
              * MSF is adopted as a WG document
              * **Thomas**: please detail what you need by DoS attach by autonomous
              cells and joining.
              * **Simon**: attacker can jam join cells.
              * **Thomas**: damage stays at the pledge, does not propagate into
              the network.
              * **Yatch**: issue is JP fills up its schedule with cells of the
              * **Malisa**: a no-brainer solution would be to have downlink traffic
              go in the shared cell.
              * **Malisa**: There are the statefull and stateless options to join
              the network
              * **Thomas**: continue discussion on the ML
          * [16.44, expected 16.40] draft-ietf-6tisch-msf, simulation campaign
          (**Yasuyuki Tanaka**, remotely) [15min]
              * Yasuyuki is preseting the updates of the 6TiSCH simulator
              * version 1.1.6 was released yesterday.
              * The purpose of the simulator is to get quick evaluation of the
              new ideas, before going to the experimental evaluation.
              * The simulator can be run over a computer cluster that allows
              faster evaluation.
              * simulator can use a connectivity trace acquired from a real
              * The simulator shows very promising performance, since it was
              evaluated with OpenWSN, and they show similar results
              * **Yatch** details the lessons learned from the MSF draft.
              * **Thomas**: are you saying that with MSF-01, addition of dedicated
              cells is too slow?
              * **Yatch**: yes, due to collisions of the autonomous cells. Even
              in some cases, dedicated cell is not added at all?
              * **Thomas**: is this a consequence of the backoff?
              * **Yatch**: yes.
              * **Thomas**: the traffic is periodic or bursty?
              * **Yatch**: it is periodic
              * **Yatch**: frame pending bit not well described in IEEE802.15.4
              standard, not sure our implementation is correct.
              * **Tero Kevinen**: action item in next week's IEEE meeting to clarify
              * **Lijo Thomas**:
              * **Yichoan**: can you detail connectivity traces from real
              * **Thomas**: runs sequence (RSSI, etc.) from database collected in
              real deployment, fixed topologies.
              * **Thomas**: Yatch, is Appendix E of the MSF-01 complete?
              * **Yatch**: yes
          * [17.03, expected 16.55] draft-ietf-6tisch-msf, experimental campaign
          (**Tengfei Chang**, remoteremotely) [15min]
              * Presents the experimental evaluation of MSF over OpenTestbed that
              is deployed in the Inria-Paris office buildings
              * Explains how the testbed works, the API, architecture, connectivity
              * Presents the 6TiSCH implementation over OpenWSN, and then the
              OpenVisualizer option
              * The experimental results shows average PDR 99.14% with 3 number
              of retransmissions. One node responsible for most losses, needs
              * The topology comes with 38 nodes, with max 4 hops?
              * **Georges** are all nodes sources, even those which relay
              mesages? what kind of traffic? What was the slotframe size?
              * **Tengfei**: all nodes generate data. 37 data sources. 1
              packet/min. Keep-alive frames on top of that (every 30 s if no other
              packet). Slotframe is 101 timeslots long.
              * Proposals from Tengfei: Only reserve autonomous cell to parent,
              Bring back the one managed Tx cell in additional to autonomous cell,
              Only send DIO when one managed Tx cell is installed
              * **Thomas**: does Appendix E contain all recommendations you're
              making or does it need additions?
              * **Tengfei**: some are not htere
              * **Thomas**: raise them on the ML so that they find their way into
              the MSF.
              > **Action item**: **Tengfei** to raise suggestions found with MSF
              on the ML, ensure get into MSF.
              * **Simon**: agree that maybe currently too much resource, could be
              allocated on demand
              * **Thomas**: what is the difference between current situation and
              your proposal, Simon?
              * **Simon**: no difference on the air. Only internal.
              * **Pascal**: lets make it to mailing list
              * **Thomas**: have you tried to consolidate your findings? Tengfei,
              do you find the same findings that Yatch does?
              * **Pascal**: let's have an interim dedicated to MSF
              > **Action item**: **Pascal** to organize an interim about MSF.
              * Questions from Jabber:  Installing TX to RPL neighbors (RPL parents)
          * [17.27, expected 17.10] draft-ietf-6tisch-minimal-security (**Malisa
          Vucinic**) [25min]
              * updates of the minimal security draft.
              * WGLC before Montreal, 2 versions published since.
              * will present major issues here.
              * stateless proxy: work outsourced to CoRE. New CoAP option for
              extended token. Now stateless JP operation.
              * Second issue: Use of confirmable CoAP message for Join Request,
              retransmission handled by CoAP
              * Third: bandwidth cap. CoAP has a congestion control mechanism. All
              is in RFC7252.
              * **Pascal**: we need to see new ideas (no netid configuration of
              the JRC, configuration of the cap) would like to see this commented
              on the ML.
              > **Action item**: **Malisa** to discuss final changes to the
              minimal-security draft (no netid configuration of the JRC,
              configuration of the cap) on the ML
              * **Pascal**: with RPL, could get info about saturation of the Root,
              the available in DODAG through DIO packet
              * new "Error" CBOR structure to carry error code of previous request
              that failed.
              * when failure of JRC, new JRC that takes over could reuse
              nonce. Proposed resolution
              * sixth issue: blacklist parameter to reject pledges that keep
              sending requests.
              * seventh issue: Link_Layer_Key that supports all modes of 15.4
              * **Malisa**: Tero could you check the answer to issue 7?
              * **Tero**: already dont, OK.
              * **Malisa**: do we need another WGLC?
              * **Thomas**: received lots of comments. Write on the ML the intended
              changes, discuss them. Then short WGLC.
              * **Suresh**: agrees with Thomas. Can also open new LC on part of
              the doc.
              > **Action item**: **Chairs** to open 1-week WGLC on changes in -09.
              * OSCORE blocking anyway for the moment.
              * **Suresh**: don't block this document because of OSCORE.
              * **Thomas**: about EDHOC, will talk with ACE chairs as we finish
              this meeting (meeting scheduling conflict)
          * [17.53, expected 17.35] draft-tiloca-6tisch-robust-scheduling (**Simon
          Duquennoy**, remote) [15min]
              * new work. Adversary could easily learn pattern of victim node and
              run selective jamming (to save energy or be less detectable).
              * Simon goes through attack algorithm and example.
              * Proposal to prevent the attack by construction.
              * uses a secret to permutate timeslot utiliszation pattern and
              channelOffset pattern.
              * **Yichoan**: this attack is targeting a single node. Attacker
              would target full network.
              * **Simon**: both cases exist.
              * **Yichoan**: why not full jamming?
              * **Simon**: to be un-noticed.
              * **Pascal**: bring this discussion to the mailing list.
              * **Simon**: will need to update this draft to reflect new version
              of minimal security.
              * feedback from the WG? Interest in this?
              * **Thomas**: it's a neat little trick, but is it a real attack? At
              bit more convinced after the discussion, as it could be an attack
              against a single node.
              * **Tero**: How can a joining node join if the cells to contact the
              JP continuously changes?
              * **Simon**: we do not shuffle slotframe.
          * [18.07, expected 18.09] AOB
              * no other business raised
          * [18.08, expected 18.10] Meeting ends

Generated from PyHt script /wg/6tisch/minutes.pyht Latest update: 24 Oct 2012 16:51 GMT -