Clone wiki

meetings / 160923_webex

DRAFT

Minutes, 23 September 2016 interim, 6TiSCH WG

Note: timestamps in PDT.

Connection details

Taking notes (using Etherpad)

  1. Xavier Vilajosana
  2. Michael Richardson
  3. Pascal Thubert

Present (alphabetically)

  1. Thomas Watteyne
  2. Pascal Thubert
  3. Diego Dujovne
  4. Georgios Papadopoulos
  5. Malisa Vucinic
  6. Marcelli (???)
  7. Michael Richardson
  8. Qin Wang
  9. Rashid Sangi
  10. Sumankumar Panchal
  11. Tengfei Chang
  12. Xavier Vilajosana

Action Items

  1. Pascal to fix the milestone ( draft name)
  2. Thomas to ask consensus on rcv initiated 6P transaction and cell suggestion
  3. Xavi to start a thread for consensus pn number of cells in response
  4. Xavi to propose to carry the link option in teh 6top protocol

Agenda

  • Administrivia [3min]

    • Approval agenda
    • Approval minutes last call

    • working with 802 [5min]

  • 6top protocol [10min]

    • agreeing on action items, milestones and next steps
      • Receiver Initiated 6P Transactions
      • Receiver 6P Cell Suggestion
      • dynamic number of cells in reply
  • Next steps for SF0 [30min]
    • Target? Experimental?
    • status and next steps
    • Cell allocation Scheme
  • AOB [2min]

Minutes

  • [07.05] (expected 07:05) Administrivia [3min]
    • Meeting starts, agenda Bashing
    • agenda and minutes of last call approve
    • udpate of charter . renaming 6top protocol from sublayer.
    • date of december to submit 6top and sf0 to the iesg. Would be desirable to send the documents by the next ietf meeting
    • Thomas: adding to the charter 4th etsi plugtest in the next year july ietf meeting (2017) [implies no plugfest in Feb.2017? I guess no]
    • paging dispatch document submitted to IESG. reviewed by all the areas. Good feedback.
    • routing dispatch is the real 6lorh, this is reviewed and will be pushed to the IESG
    • routing dispatch and paging dispatch drafts should update rfc6550-51-52-53.
    • minimal draft is in the internet area review. Hanging there.
    • Michael: every second tuesday meeting of the security design team.
  • [07.??] (expected 07:08) working with 802 [5min]
    • An IEEE and IETF meeting in Paris happened last week. discussion about things that are crossing both groups.
    • 6TiSCH IEs in 6top. The IETF is requesting to the IEEE.
    • 6lo is requesting an Ethertype to the IEEE.
    • There will be an official ethertype like IPv6.
  • [07.??] (expected 07:13) 6top protocol [10min]
    • Thomas: draft is almost ready.
    • 2 ideas that are floating. Receiver initiated transactions. Receiver cell ...
    • allow the node to limit the numbr of cells if not enough room in the packet due to IE
    • Xavi: I'm handling that. 1st idea (rcv initiated transaction): consensus? If yes I can handle it.
    • Thomas: action item to get consensus on that on the ML
    • Xavi: no strong opinion. Mechanism looks simple; again need consensus.
    • Pascal: 2 action items for Thomas, one for Xavi
    • Xavi: also need to validate the draft on missing ack. check that there is a timeout on the 2 way transaction?
    • Thomas: only missing point is security, making progress. Very close to a full package
  • [07.??] (expected 07:23) Next steps for SF0 [30min]
    • Thomas: reviewed SF0. Needs work; This is a key piece, the default brains.
    • Thomas: slide 18 identifies questions, Diego is the only author present
    • Need level of evaluatuion / proof to get std track.
    • Pascal: need to track the issues as tickets on the IETF tracker, please use different threads for each ticket
    • Pascal to handle the issue tracking in the IETF tracker to track the threads to resolution.
    • many acronyms in the draft makes it confusing. Simplify, the acronyms for the data flows.
    • outband bandwidth is not calculated correctly. Check the formulation.
    • whitelist/blacklist is like a not, to say if we want to reserve cells out of the available (blacklist). Whitelist indicates just the list of cells that wants to be allocated. In the metadata this is specified.
    • timeout calculation: is calculated as the number of cells until the next opportunity to transmit. This timeout should be larger than the normal delay instead as we need to take into account the PDR.
    • tengfei: the timeout should be related to the backoff period. Not to the PDR.
    • 6top protocol packets are sent on shared slots only?
    • Pascal it should be more flexible, 2 extra slots per peer is sometimes too much, somtimes not enough. SHould be able to use chared slots.
    • Thomas: it is up to the minimal configuration to decide the amount of shared cells.
    • Pascal: That works for a minimal only solution, because we can tune the size of the slotframe. But here it will be dictated by eg how many slots are needed for all these peers, and one shared may not be enough. Suggestion is that SF0 also allowates shared slots taht teh parent exposes to selected children.
    • Thomas: SF0 is a simple mechanism that is not aware of parent / child, keep it simple. Also the concept of shared slots is that all my neighbors see it.
    • Pascal: a shared slot is used by everybody that knows about it. It is not a transitive proerty anyway.
    • Xavi: proposal to use the link option when a cell is requested in 6top. Action to add linkoption to the 6p draft.
    • Pascal: agrees to have the linkoption but by now we do not use it in the sf0
  • [08.05] (expected 07:53) AOB [2min]
    • nothing
  • [08.08] (expected 07:55) Meeting ends

Updated