[6tsch] minutes webex 21 June 2013

[Thomas Watteyne <[e-mail]>]

All,

You will find the minutes of the last webex below, and the presented slides
attached.

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

Thanks to Xavi and Dominique for taking notes!

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

Thomas

-----

Minutes Webex 21 June 2013, 6TSCH group

Note: timestamps in PDT.
Taking notes *(using Etherpad)*

   1. Xavi Vilajosana
   2. Dominique Barthel
   3. Thomas Watteyne

Present *(alphabetically)*

   1. Alfredo Grieco
   2. Dominique Barthel
   3. Guillaume Gaillard
   4. Kris Pister
   5. Maria Rita Palattella
   6. Pascal Thubert
   7. Pouria Zand
   8. Raghuram Sudhaakar
   9. Thomas Watteyne
   10. Tina Tsou
   11. Tom Phinney
   12. Xavi Vilajosana

Recording

   - Webex recording (audio+slides,streaming)
   -
   https://cisco.webex.com/ciscosales/lsr.php?AT=pb&amp;SP=MC&amp;rID=69395152&amp;rKey=9c437dc2a66e5d34<https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=69395152&rKey=9c437dc2a66e5d34>
    *[62min]*

Slides

   - slides_130621_webex.ppt<https://bitbucket.org/6tsch/meetings/src/d3f0785cf405ee50ad3ee31edb1e02645ca7117c/130621_webex/slides_130621_webex.ppt?at=master>:
   slides shared during the call

Agenda

   - draft-thubert-6tsch-architecture-02 *[5min]*
   - draft-vilajosana-6tsch-basic-00 *[10min]*
   - Architecture with remote BBR *[10min]*
   - Soft cell assignment: random or not? *[20min]*
   - Track IDs *[10min]*
   - AOB *[5min]*

Minutes

   - *[08.05]* Meeting starts
   - *[08.05]* Pascal starts the recording
   - *[08.05]* Agenda *[Pascal]*
      - draft-thubert-architecture v2
      - draft-vilajosana-basic v0 (thank you Xavi!)
      - Architecture with remote BBR (by Thomas)
      - Soft cell assignment: random or not
      - Track IDs
      - AOB
   - *[08.06]* adopting minutes *[Pascal]*
      - let's do a call for adoption of the previous meeting's minutes from
      now on
      - any concerns with last call's minutes?

      rough consensus on the call

      - last call's minutes are adopted
      - note: we are recording this call
   - *[08.07]* draft-thubert-architecture *[Pascal]*
      - ROLL flow label draft (
      http://tools.ietf.org/html/draft-thubert-roll-flow-label): using the
      flow label we can skip to have another encapsulation and use it for the
      hop-by-hop
      - RPL can use hop by hop option
      - we can forward about anything in a slot (a la GMPLS), i.e. tunnel
      mode
      - transport mode: dmac to 0xffff at ingress, restored at egress
      - Tunnel Mode:
         - if we setup a track the forwarding is done at the 6tus layer
         - who sets the mac address and what mac addess is there?
         - Using the tunnel abstraction to switch between technologies,
         assuming a node can have 2 interfaces (e.g. WirelessHART and
         IEEE802.15.4e), the tunnel model can transport the
WirelessHART payload
         tunneled in the IEEE802.15.4e using 6tus tunnel and the
restore it at the
         egress router.
         - *[Thomas]*: we need to look closely at the implications,
         especially on the security aspect
         - *[Thomas]*: it might be easier to do if:
            - the WirelessHART and IEEE802.15.4e slots are the same length
            - some coordinated schedule of both networks is happening,
            essentially building a collision-free schedule across both networks.
         - *Action*: *ALL* to read proposed -02 draft (
      https://bitbucket.org/6tsch/draft-thubert-6tsch-architecture/src) and
      provide feedback.*Pascal* to publish after rough consensus.
   - *[08.19]* draft-vilajosana-6tsch-basic-00 *[Xavi]*
      - *Xavi* presents the draft published at
      http://tools.ietf.org/html/draft-vilajosana-6tsch-basic-00.
      - We were discussing the minimal configuration for 6TSCH at last call.
      - Draft contains the outcome of that discussion.

      Xavi shares his screen, showing the draft

      - Main purpose of draft is for interop testing.
      - Xavi goes through parameter values.
      - Longer than 10ms slot needed for slower platforms
      - Basic schedule, static schedule, same for all nodes, 5 active
      slots, rest is sleeping.
      - Recommends neighbor management information base.
   - *[08.30]* Architecture with remote BBR *[Thomas]*
      - Addresses the case of several BBRs, on different subnet. ND
      proxying needed for
      http://tools.ietf.org/html/draft-thubert-6lowpan-backbone-router-03 to
      work.
      - Several possible architectures : tunnel, combined PCE/router, hybrid
      - Hybrid: the PCE does the proxying of all the nodes in the LLN, the
      PCE manages and has explicit connections to the BBRs.
      - Keep PCE and ND separate elements. 6tsch does not define anything
      about how PCE and BBR communicate.
      - *[Thomas]* 6TSCH should not take on the task of defining BBR-to-PCE
      communication. But we should not exclude in our specification any of the
      three approaches and if someone wants to go for them this should not
      exclude them from the standard.
      - *[Pascal]* Push as much work as we can to the PCE/discovery. Add to
      architecture.
      - *[Pascal]* add some text on the architecture draft telling that can
      be done in an open way.
      - *[Thomas]* many ways of doing this. Should describe a reference
      architecture but leave it open
   - *[08.38]* Soft cell assignment: random or not? *[Thomas]*
      - This problem applies only to distributed scheduling.
      - Open question: Is a purely random good enough?
      - Answer will depend on the amount of traffic in the network. We need
      to indentify the threahold traffic at which point it is NOT good enough
      (possible collapse).
      - 2 neighbors negociate the allocation of an extra cell, and have to
      decide on a slotOffset/channelOffset. The problem is that neighbors can
      choose the same cell and then collisions occur.
      - Two methods:
         - Random selection: select cell randomly, and hope for the best.
         If collisions happen, a monitoring function detects then and
picks another
         (random) location for that cell.
         - Informed selection: maintain some state and try not to pick same
         cell as other neighbors. Collision can still happen, but less likely.
      - In both cases, detecting collisions is crucial, and I believe this
      was agreed on on the ML.
      - *[Pouria]* presents picture. Shows 2-hop neighborhood. Shows
      conflicting edges of two nodes. Node A can ask for one hop
neighbor's cell
      usage. It can get up to 2 hop neighbors as 1-hop neighbors can send that
      information. By combining that information, the figure can be
build. During
      a negotiation node A can send a candidate list to the neighbor.
      - *[Thomas]* There are 2 steps in solving this:
         1. how much of a problem is it if we just do random.
         2. If random is not good enoug, what is the best approach
      - Problems with random. What is the collision probability? What is
      the traffic on my network that causes random selection to not work. How
      often will a collision happen? Is is possible to evaluate the overhead of
      re-negotiation, and compare that to the overhead to maintain state?
      - There are open questioms
      - *[Thomas]* Pouria, willing to work on this?
      - *[Pouria]* yes.
      - *[Xavi]* look at P2P community, not reinvent.
      - *[Kris]* No doubt that informed will do better than random.
      - *[Thomas]* example of Trickle. RFC says one needs to define what is
      consistency and inconsistency. Opinions here on what is a
consistent state?
      "no collision" as the consistent state is being debated on the ML.
      - *[Kris]* a node won't know if it's a collision inside network or
      with something external. Only thing it knows is "this cell
doesn't work for
      me".
      - *[Thomas]* take as action item to start looking at problem of
      figuring out how bad random approach is, boundary with informed decision.
      Who would be interested.
      - *[Xavi]*: I'm interested.
      - *[Pouria]* I'm interested.
      - *[Alfredo]* I'm interested.
      - *[Alfredo]* the problem is that purely random selection can be done
      many different ways. We could for example have some dependency on the hop
      count from the DAGroot, could help with channel re-allocation. Implicit
      state, related to routing topology.
      - *[Thomas]* allocate pieces of matrix to differnet parts of DAG.
      Less fighting. Let's put this to the mailing list and come up
with numbers.
   - *[08.58]* Track IDs *[Thomas]*
      - discussion stared by Qin. If we don't have clear track ID, it's
      harder to match cells to tracks.
      - *[Pascal]* We could use of RPL Instance ID:
         - instanceID: each node has 64 available instanceIDs to manage.
         - the PCE can install route.
         - who selects the instanceID? source? destination? p2p rpl uses
         source to select instanceID.
         - what about broken track?
      - *[Thomas]*: 6LoWPAN would compress this nicely. Possibly through
      contexts?
         - *[Pascal]* the source mac is still compressed with 6lowpan.
         InstanceID is kept on the state of the tunnel.
         - *[Pascal]* Hop by hop option removed compression opportunity.
      - *[Thomas]*: we will carry on this dicsussion on the mailing list,
      because time has expired.
   - *[09.07]* AOB *[Thomas]*
      - *Thomas* calls for Any Other Business

      no other business

      - *[09.08]* meeting ends