* 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 —  
Chairs
 
 


IETF-100 6tisch minutes

Session 2017-11-13 1550-1720: Bras Basah - Audio stream - 6tisch chatroom

Minutes

minutes-100-6tisch-00 minute



          # 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
          
          



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