Subject: [6tisch] Minutes webex 06 June 2014

From: Thomas Watteyne <[email-masked]>
Date: Sat, 7 Jun 2014 01:53:06 -0700

All,

You will find the minutes of the last webex below.

FYI, all the minutes and slides are archived a
https://bitbucket.org/6tisch/meetings/.

Thanks to Xavi and Pascal for taking notes.

As usual, please fix anything we might have missed directly in the e-mail
and reply.

Thomas

-----

Minutes Webex 6 June 2014, 6TiSCH WG

Note: timestamps in PDT.
Connection details

   - Webex Link
   <https://ciscosales.webex.com/ciscosales/j.php?ED=219615007&UID=481905242&PW=NZTRkNDAwOTE1&RT=MiMyMw%3D%3D>
   - Live etherpad for minutes
   <http://etherpad.tools.ietf.org:9000/p/6tisch?useMonospaceFont=true>
   - Topic: 6TiSCH Weekly
   - Time: 8:00 am, Pacific Daylight Time (San Francisco, GMT-07:00)
   - Meeting Number: 206 802 913
   - Meeting Password: sixtus
   - CCM: +14085256800x206802913

Resources

   - Webex recording
   <https://cisco.webex.com/ciscosales/lsr.php?RCID=ee4f8840d9ac4b58a3f49597521e24ea>
    *[46min]*
   - Wiki <https://bitbucket.org/6tisch/meetings/wiki/140606_webex>: wiki
   page for this meeting
   - slides
   <https://bitbucket.org/6tisch/meetings/src/master/140606_webex/slides_140606_webex.ppt>:
   slides shared during the call

Taking notes *(using Etherpad)*

   1. Xavi Vilajosana
   2. Pascal Thubert
   3. Thomas Watteyne

Attendance *(alphabetically)*

   1. Bryan McLaughlin
   2. Diego Dujovne
   3. Kazushi Muraoka
   4. Maria Rita Palattella
   5. Michael Richardson
   6. Nicola Accettura
   7. Pascal Thubert
   8. Pat Kinney
   9. Patrick Wetterwald
   10. Pouria Zand
   11. Raghuram Sudhaakar
   12. Thomas Watteyne
   13. Xavi Vilajosana

Action items

   - *Pascal* to publish new architecture draft version and remove issues
   in tracking system.
   - *Thomas* to close issues on 6TiSCH Architecture once new version
   published
   - *Pascal* to e-mail detailed requirements on using different CCA
   mechanism for deterministic and non-deterministic traffic
   - *Pascal* to create a doodle to schedule an ad-hoc call dedicated to
   terminology
   - *Xavi* to follow on the ML on how to mark the slot as ADV slot and
   DATA slot so we can have a single slot

Agenda

   - Administrivia *[10min]*
      - Approval agenda
      - Approval minutes last call
      - PlugFest: Confirming dates
      - Closing architecture draft issues
   - Update on 6top interface *[15min]*
      - Create 1 global issue or multiple more detailed ones?
   - Minimal draft *[15min]*
      - Continue discussion on new proposal by Xavi
   - Terminology discussion *[15min]*
      - If time permits
   - Next meetings *[2min]*
   - AOB *[1min]*

Minutes

   - *[08:05]* Meeting starts
   - *[08:06]* Administrivia *[10min]*
      - Approval agenda

      No issues raised. Agenda approved.

      - Approval minutes last call

      No issues raised. Minutes approved.

      - Two security calls during the week. Minutes have been published.
      - *[Maria Rita]* needs to clarify points with Qin and Xavi about 6top
      interaction.
      - *[Thomas]* would be good to have OTF for IETF meeting so we can
      implement/show at plugfest.
      - *[Michael]* goal of the security design team. There are 2 options
      about organization of drafts, consensus goes to one direction,
but it seems
      that there will be 2 documents that will describe the security
architecture
      for IETF90.
      - PlugFest: Confirming dates
         - event has been approved approved.
         - will be Sunday 20th 9-13
         - open for proposals
         - Pascal and Thomas asked for a 90min WG meeting early in the week
         to allow for attendees to be present at both with minimal expense
      - Closing architecture draft issues
         - Hard deadline for IETF submission 7/4
         - 3 major issues raised by Michael
         - answers and new text added

         Action item: *Pascal* to publish new architecture draft version
         and remove issues in tracking system.

         - Update on 6top interface
      - We need to call for consensus on the ML about the different issues
      raised by Qin
      - Use CoAP over WrapperIE
      - If the CoAP payload is too long, the proposed solution is to use
      CoAP-Block. CoAP-Block packets are ACK'ed. Two options for the ACKs:
         - use/overload 15.4e ACKs
         - use a separate L2 DATA packet to carry L2.5 ACKs
      - the latter seems cleaner to use, safer in terms of timing.
      - open question about CoAP-Block option v.s. custom fragmentation.
      - *[Raghuram]* We need block option when does not fit in one frame.
         - A schedule may not fit and may be larger than one IE block so
         need for block option.
         - One traditional case is when the schedule information do not fit
         to the wrapper IE payload (usual case).
         - Option to use the enhanced ACK to confirm the Block packet
         reception.
         - prefer clean layer separation, i.e. L2 data packet to carry L2.5
         response.
         - I prefer to maintain the layer separation. Mixing L2 and acks
         maybe layer violation.
         - New proposal: programmatic API between L2 and CoAP interface.
         Will maintain separation of concerns and avoid cross-layering.
      - ACTION: to comment on the ML about the use of App layer
      fragmentation vs Block Option
      - *[Thomas]* summary:
         - Using CoAP as a pure management protocol,
         - We want the same implementation for CoAP at L4 and at L2.5.
         - We use block option to have standard encapsulation and
         fragmentation, the block can be used with or without the ACK.
      - if we opt for custom fragmentation solution, the code footprint
      increases since we will need 2 different code bases running.
      - *[Pat]* We need to focus on the constrained aspects of the devices.
      Anything we can do to reduce footprint needs to be considered, but also
      anything that reduces the amount of communication.
      - *[Thomas]* What we are trying to do is propose a very generic
      mechanism to allow a node to access the 6top interface on another node
      exactly as the PCE would do that. This is used in the distributed case.
      - We are looking for the mechanism that enables that identical
      interaction.
      - *[Michael]* I hear that Thomas wants to reuse the interactions.
         - In the PCE case, there must be an application-layer ACK (i.e.
         CoAP)
         - If there is a PCE, the interaction will be at L7 so this
         requires app level acks.
         - Receiver must be prepared to send an ACK. This must be
         implemented. Sounds like recommendation that the peer should
never send a
         confirmable message. This is a local matter to the peer.
Depending on the
         chip, the sender may be able - or not - to know about L2 ACK.
We need to
         support both.
         - the receiver always needs to be prepared for both situations (be
         able to ACK or not). The PCE might be multiple hops away so
ACKing cannot
         be avoided. In distributed approach, we do not know if layer
above can ACK,
         or we need to do it. So the node must be able to handle both
situations.
      - 6top updates
         - Qin sent a mail listing open 6top issues.
         - Question is whether to write a new draft, or integrate in
         existing 6top-interface, 6top-sublater, 6TiSCH-CoAP drafts
         - *[Pascal]* would keep the current structure of the 6top drafts.
      - *[Thomas]* TSCH draft needs also to be updated, including
      terminology, etc. Will coordinate with Patrick.
      - *[Patrick]* sounds good.
   - Minimal draft *[15min]*

   *Xavi* has trouble speaking, Thomas presents on his behalf, Xavi
   confirms by Webex chat.

   - Let's continue discussion on new proposal by Xavi.
      - idea is to make minimal draft more flexible
      - do not specify slotframe size, make it dynamic.
      - the DAGroot advertises the slotframe size and, as motes join, keep
      advertising the same information
      - the slotframe will have 1 active slot

      Action item: *Xavi* to follow on the ML on how to mark the slot as
      ADV slot and DATA slot so we can have a single slot.

      - *[Pascal]* propose to do CCA more tunable so the minimal operation
      CCA can be longer
         - The size of the slotframe determines the throughput. The control
         loop can occur in another period in another slotframe. Is there is
         something we can do so the data plane has lower priority than
the control
         plane.
         - There is a priority control that already does that. Pat will be
         back with more information.

         *Pascal* to e-mail detailed requirements on using different CCA
         mechanism for deterministic and non-deterministic traffic

         - Terminology discussion *[15min]*
      - Let's schedule a dedicated meeting for this discussion.
      - *[Maria Rita]* +1

      Action item: *Pascal* to create a doodle to schedule an ad-hoc call
      dedicated to terminology

      - Next meetings *[2min]*
      - Monday 6/9, 7-8am PDT, Security DT
      - Monday 6/16, 7-8am PDT, Security DT
      - (to be scheduled) terminology ad-hoc meeting
      - Friday 6/20, 8-9am PDT, 6TiSCH webex
   - *[09:00]* AOB

   No other business raised.

   - *[09.00]* Meeting ends