1. 6tisch Avatar 6tisch
  2. admin
  3. meetings

Wiki

Clone wiki

meetings / 140606_webex

View History

Minutes Webex 06 June 2014, 6TiSCH WG

Note: timestamps in PDT.

Connection details

  • Webex Link
  • Live etherpad for minutes
  • 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

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

Updated