[6tisch] Minutes, IETF 96 6TiSCH WG Meeting

["Pascal Thubert (pthubert)" <[e-mail]>]

Agenda and Meeting information

Meeting        :   IETF96 Monday, July 18, 2016 (CEST)

Time           :   14:00-15:30 Monday Afternoon session I (90min)

Location       :   Room Bellevue, Intercontinental Berlin

Chairs         :   Pascal Thubert <[e-mail]>

                   Thomas Watteyne <[e-mail]>

Responsible AD :   Suresh Krishnan

Live minutes   :   http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-6tisch

Live feeds     :   https://tools.ietf.org/agenda/96/#96-mon-1400-6tisch



Other 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                                  [5min] (Chairs)



   Note-Well, Blue Sheets, Scribes, Agenda Bashing



New charter and status docs                      [20min] (Chairs)

   * Status Documents

   * Status 6lo / ROLL

   * Milestones

   * Action Plan



Dynamic Scheduling

   * <draft-wang-6tisch-6top-protocol-01>        [15min] (Xavier Vilajosana)

   * <draft-dujovne-6tisch-6top-sf0-01>          [15min] (Diego Dujovne)



Security

   * status of the work and action plan          [10min] (Michael Richardson)



Plugtests News

   * ETSI 6TiSCH/6lo plugtests Results           [10min] (Miguel Angel Reina Ortega)

                                                         (Maria Rita Palattella)



Unchartered items, time permitting

   * <draft-satish-6tisch-6top-sf1-01>           [10min] (Satish Anamalamudi)



Any Other Business                                [2min] (Chairs)

Resources

  *   [agenda:] (https://datatracker.ietf.org/meeting/96/agenda/6tisch/)
  *   [presented slides:] (https://datatracker.ietf.org/meeting/96/session/6tisch/)

Summary

TODO

Action items
Volunteers

  *   Scribes
     *   Dominique Barthel
     *   Diego Dujovne
  *   Jabber
     *   Ines Robles

Minutes

  *   [14.01] (expected 14.00) Intro and Status [5min] (Chairs)
  *   Note Well
  *   any comment to the agenda? none. Agenda approved
  *   [14.03] (expected 14.05) Status [20min] (Chairs)
  *   -minimal going through IESG reveiw
  *   6LoRH passed LC, now at ROLL, waiting for 6lo-paging-dispatch, itself missing shepherd review
  *   news from 6man: 2460m 4291 and 1981 bis'sed to beacom Internet standard. Discussion on header insertion. Some would like to clarify that header insertion cannot be done. Would break a lot of stuff. Chime in!
  *   6P protocol
  *   security work kickstarted (michael)
  *   Suresh: -minimal has to go through IETF last call before IESG. Another issue came up: meeting tomorrow on policy for copyright on IEEE documents. 6tisch minimal has references to copyrighted material from IEEE.
  *   [14.09] (expected 14.25) <draft-wang-6tisch-6top-protocol-00> [15min] (Xavier Vilajosana)
     *   version -01 submitted recently. Used to be -sublayer draft.
     *   this text has clarification on 6top concurrent transactions
     *   today discuss a few points that came up during ETSI plugtest.
     *   6p command to count cells in the schedule for a link. extend the command to get the status in both directions of the link. propose to change name from 6p count to 6p status.
     *   6p does not paginate. can add pagination add an offset for each page. another command: list from A->B and B->A (TX and RX) cells. A and B neighbours.
     *   detect if a node and its neighbour is consistent after disconnection and restore state or reset. keep the status by defining a Schedule Generation
     *   new NO_RESOURCES error: not enough cells for request.
     *   consistency: ensure that both ends agree on their schedule, especially after disconnection, reboot, etc. Could CLEAR and restart the whole process. Change the seqnum byte to hold a shorter seqnum and a 2 bit lollipop counter ("generation" number) for each link direction. 3 states: starting, value 1, value2. Once it's going, alternate between values 1 and 2.
     *   Thomas: what happens when schedule unknown Do both ends have to CLEAR?
     *   Xavi: Both have to clear.
     *   Thomas: is a one bit counter enough? Xavi: yes, because requirement to have only one transaction on-going.
     *   Pascal: how to know that One or more routers around who has the state about the node (me). What to do? TBD
     *   Thomas: these are issues that arose during the plugtest yesterday. We have not yet discussed them on the mailing list. Will do. Comments from implementors? Pascal: this means will probably not be done in July as planned. Xavi: if you think our proposals above create issues, tell us on the mailing list. If nothin gheard, will push a new draft out quickly.
  *   [14.28] (expected 14.40) <draft-dujovne-6tisch-6top-sf0-01> [15min] (Diego Dujovne)
     *   this used to be "on-the-fly scheduling". Now default scheduling function aka SF0.
     *   algorithm to measure bandwidth usage (short of having hte application communicate its requirement to us).
     *   the number of cells is converted to the input for the allocation policy
     *   Establish a high SF0THRESH for overprovisioning
     *   Thomas: don't understand drawing on slide 4.
     *   Nicola, Pascal, Thomas: Threshold arrow should be drawn one-way, going down from current scheduled cells.
     *   Recommendation: convert the figure 4 in 3 figures. One that represents the case that there are too many cells, another where there are more cells needed and another where the number of cells is fine.
     *   whitelist: selection of the ch.offset randomly. The neighbor selects the cells sequentially in case there is a collision. (i,e if the cell is used proposes the next cell in the list).
     *   blacklist:
     *   Pascal: use of blacklist-> administrative to reserve some cells. Other more functional to avoid noisy channels, etc... Why the concept is comming here?
     *   Diego: a black list is something that has been allocated to something else. Is a mechanism to internally reserve/protect some cells.
     *   Pascal: there should be a mechanism to avoid collisions in the selection/ or to reuse too many times the same cell.
     *
     *   Timeout: if no news from neighbor, cancel the state requested by command.
     *   There may be concurrent requests from several neighbors (not concurrent requests for the same neighbor).
     *   these concurrent requests may prevent from accepting the resquested allocation.
     *   Use 1 bit from the metadata field to differentiate between concurrent transaction or busy because there are no processing resources.
     *   "No processing ressource" means no CPU ressource or other reason, please come back later.
     *   "ongoing concurrent transaction" means some other neighbor requested cell range that overlap with your request, or somtehing similar.
     *   todo: adapt tp changes in 6P. Cell relocation: on which PDR? is 20% below average (across all cells to same neighbor?) a good value? Cell garbage-collection when neighbor has disappeared?
     *   Questions?
     *   Tengfei Chang: on slide 4, how is "more" computed?
     *   Thomas: this is essential work, SF0 is meant to be the generic, default scheduling. We would love feedback from implementors to check that it fits the needs. Or even simulation.
     *   Thomas: next we'll have a presentation of SF1. Authors, please position SF1 wrt SF0 so the WG can understand if we should merge, pick one, and keep both.
     *   Pascal: depnding of node position in the network (center, edge), reaction to cell shortage might be different.
     *   Xavi: why differentiate between "node busy"and "concurrent transaction"? Will retry in any case. Diego: differnet timeout value

·        [14.58] (expected 14.55) Status of the security work and action plan [10min] (Michael Richardson)

     *   security design team, resumed work in May 2016.
     *   -00 draft will be out this week. Table of contents presented here.
     *   Explain motivation, assumptions and restrictions. Protocol bandwidth conservative join cordination entity to control the joining sequence(?)
     *   Code reuse: No security protocol not already used for other purposes (if single use, less chances of being maintained, etc).
     *   not reinvent DTLS. OS COAP evolution?

o   Zero conf: too expensive?. Acceptable.

o   Göran Selander: where does OSCOAP belong? application layer protocol on top of COSE. We are going to ask for adoption in CoRE, which is where it belongs. Diffie-Hellman (EDHOC) is less clear.It will be presented at ACE WG meeting this week. Michael: again, we'd rather not use a protocol that's not already in the device for some other purpose.

     *   Göran: used also for firmware updates. You have it already in your device.
     *   Carsten Bormann: COSE working group has not finished the main task. It will/may? be closed once the main draft is done.
     *   Not throw away the good design patterns we had before.
     *
     *   [15.07] (expected 15.05) ETSI 6TiSCH/6lo plugtests Results [10min] (Miguel Angel Reina Ortega/Maria Rita Palattella)
     *   supported by OpenMote for golden HW and OpenWSN for golden SW.
     *   two full days spread over 3 calendar days.
     *   test description by TW, MRP, ... for 6TiSCH and CB+KL for 6lo.
     *   6TiSCH had 20 tests. "85%" interoperability. Tests also prompted for improvements in 6P.
     *   6lo NFC: "80%" interoperability. Sniffing Mechanism
     *   6lo BBR: 66%. Actually, many could not be run at all. Most of the tests that ran actually worked.
     *   take-aways: advertize event earlier in advance. Have a pre-test session.
     *   Thomas: discussing with Miguel/ETSI about next event, maybe somewhere in Europe in Feb 2017, or at IETF meeting in July 2017 (Prague).
     *   Pascal: thanks to ETSI for organizing this.
     *   [15.15] (expected 15.15) <draft-satish-6tisch-6top-sf1-01> [10min] (Satish Anamalamudi)
     *   need for SF!? end-to-end scheduling for real time applications. Schedule isolated traffic flows.
     *   background: RSVP-MPLS and RSVP-GMPLS.
     *   Pascal: in 6TiSCH Architecture, we have notion of a track. Please use it in your design.
     *   Pascal: More than defining the algorithm, defining a path here.
     *   each cell is implicit label as per GMPLS.
     *   Satish goes through examples of protocol operation.
     *   Pascal: this is not jsut allocation algorithm, this is path-setup alogrithm. Not currently chartered for that.
     *   Pascal: the group is interested, keep working on it, but the WG cannot adopt it (yet).
     *   xxx: .. time ? Satish: freshness of allocation ...
     *   Xavi: many papers of this topic.
     *   Xavi: timeslot is enough as a label.
     *   Xavi: slotframe ID should be part of label, in case you have more than one slotframe.
     *   [15.30] (expected 14.25) Any Other Business [2min] (Chairs)
     *   info session on F-Interop tonight. Live demo.
     *   no other business