Subject: [6tisch] Minutes OTF discussion 12 June 2014

From: Thomas Watteyne <[email-masked]>
Date: Tue, 17 Jun 2014 17:07:39 -0700

All,

You will find the minutes of the last OTF discussion at
https://bitbucket.org/6tisch/meetings/wiki/140612_webex_otf, also
copy-pasted below.

Please fix anything we might have missed directly in the e-mail and reply.

Thomas

---

Minutes Webex 12 June, OTF call 6TiSCH WG

Note: timestamps in PDT.
Info

   - When: Thursday 6/12 10-11pm PDT
   - Webex:
      - link:
      https://cisco.webex.com/cisco/j.php?J=209434437&PW=NMjIxNDdkYTUz
      - Meeting Password: 6tisch
      - Meeting Number: 209 434 437
   - Topic: 6top-OTF interaction, updates of OTF draft

Agenda

   - 6top-OTF interaction
   - Status of the OTF draft
   - TODO for having a new complete version by cutoff date

Slides

   -
   https://bitbucket.org/6tisch/meetings/src/master/140612_webex_otf/140612_webex_otf.ppt

Taking notes *(using Etherpad)*

   - Xavi Vilajosana
   - Thomas Watteyne

Attendance *(alphabetically)*

   - Diego Dujovne
   - Maria Rita Palattella
   - Nicola Accettura
   - Pascal Thubert
   - Qin Wang
   - Thomas Watteyne
   - Xavi Vilajosana

Action items

   - *Pascal* to prepare a 5min presentation to describe/discuss/present
   track management in the following 6TiSCH meeting.

Minutes

   - *[22.03]* Meeting starts
   - *[Maria Rita]* Interactions OTF / 6top
      - When OTF needs a new softcell, needs to be associated with a bundle
      which comes with a track
      - We have multiple tracks. We may specify the trackID or not, in the
      latter case the cell may belong to any track. But when should OTF ask for
      such a trackless cell? And if so, what is the mechanism to assign to a
      track?
   - *[Thomas]* Tracks are used to separate flows. If we are using OTF,
   everything is soft-cells and everything is best effort. So tracks seem to
   be something not needed, as we do no have the notion of different flow from
   a QoS point of view.
   - *[Pascal]* Huge confusion involving deterministic tracks set up by the
   PCE, and the IP link between to adjacent nodes. OTF plays on that second
   case. The PCE has assign hard cells. The track can be used to mix
   deterministic and best effort traffic. Imagine a packet in a track that for
   some reason finds a track that is congested; the node might use a best
   effort cell for one hop, but in the next hop recovers the track.
   - *[Thomas]* I envision an OTF flexible enough so it can be used without
   any central PCE.
      - OTF decides when to reserve cells according to dynamic needs.
   - *[Qin]* Clarification: two options:
      - associate a soft cell with a single best-effort track, or
      - associate a soft cell with multiple tracks at the same time
   - *[Maria Rita]* vision aligned with Pascal: cells are assigned to
   tracks.
   - *[Qin]* The CREATE soft cell command take trackid as a parameter. If
   this id is set to 0x00, the cell is considered best-effort.
   - *[Pascal]* I think OTF needs to play only on best effort tracks. Not
   play by now on end to end flows.
   - *[Thomas]* single hop algorithm. When you ask 6top to create an extra
   soft-cell, it is 6top which selects the exact cell.
   - *[Maria Rita]* despite considering OTF a simple allocation mechanism,
   the selected cell belongs to a track.
   - *[Pascal]* we decided that trackid 0x00 means best effort, outside of
   the flow priorities, would be used.
   - *[Thomas]* The concept of track in OTF is something that can be elided
   as all cells will be scheduled in the same best effort track.
   - *[Maria Rita]* OTF will always check the total BW between 2 neighbors.
   - *[Pascal]* variable traffic exists, we may want to change the size of
   a track we may want to play with the BW allocated to a track but this will
   require end to end traffic flow management such as RSVP.
      - In traditional IP, when there is excess traffic, frames are placed
      in best effort tracks in order to cope with too much demand.
   - *[Thomas]* if we start with the common BW on the best-effort track, it
   will be a very good start. Enables us to implement that for the plugfest.
   - *[Qin]* OTF can look at queues and decide what to do. Is that what you
   mean?
   - *[Thomas]* OTF will decide to add cells to a particular neighbor
   according to the size of the queue.
      - What if we have more than one queue? the concept of queue is an
      implementation decision, at the end there is an order that
enables to sort
      all packets in a single queue according to their priority and
destination.
   - *[Qin]* Node A has 3 tracks, best effort tracks. All of the packets
   are in a queue. track 1 has more demand.
   - *[Pascal]* there are no tracks. Only neighbors.
   - *[Thomas]* let's forget about tracks in the context of OTF.
   - *[Pascal]* we need to differentiate layer 3 flow management from layer
   2 flow management.
      - OTF is a L3 thing, L2 plays with end to end tracks, it uses a
      reservation protocol.
   - *[Pascal]* proposes to list the possibilities in the architecture
   draft. It might be an enumeration to have a notion of what is possible and
   what we address.
   - *[Thomas]* we need to talk about queuing behaviors and track
   management. In this call however is out of scope.
   - *[Pascal]* use 5min in the following meeting to
   describe/discuss/present track management.