[6tsch] minutes webex 31 May 2013

[Thomas Watteyne <[e-mail]>]

All,

You will find the minutes of the last webex below, and the presented slides
at https://bitbucket.org/6tsch/meetings/.

Thanks to Xavi and Dominique for taking notes!

Please note that I've changes the format a bit to give an* executive summary
* of:
- the *consensus *we had on the phone (to be confirmed on the ML)
- the new *ideas *to be developed
- the* action items*.

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

Thomas

---

# Minutes Webex 31 May 2013, 6TSCH group #

Note: timestamps in PDT.

Taking notes (using Etherpad)
-----------------------------

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

Present (alphabetically)
------------------------

* Alfredo Grieco
* Dominique Barthel
* Herman Storey
* Maria Rita Palattella
* Pascal Thubert
* Pouria Zand
* Raghuram Sudhaakar
* Robert Assimiti
* Thomas Watteyne
* Tina Tsou
* Tom Phinney
* Xavi Vilajosana

Recording
---------

* Webex recording (audio+slides,streaming)
*
https://cisco.webex.com/ciscosales/lsr.php?AT=pb&SP=MC&rID=68663737&rKey=2f0f3d8299a89515[65min]

Slides
------

* [slides_130531_webex.ppt](
https://bitbucket.org/6tsch/meetings/src/3c563fb04b09c16df9e9a216e3bbca907ac9dd08/130531_webex/slides_130531_webex.ppt?at=master):
slides shared during the call

Agenda
------

* Logo Challenge [3min]
* Berlin Update [3min]
* 6lo [3min]
* Multiplexing Tracks [10min]
* Explicit Labels [10min]
* Forwarding Modes [10min]
* Bundle Size and ETX [10min]
* "Simplest TSCH" draft [10min]

*Executive summary*
*-----------------*
*
*
** Rough consensus to be confirmed on mailing list:*
*    * We need to take retransmissions into account when building the
schedule, and have retransmissions happen on the same track that first
attempt.*
*    * We will not support tracks between merged or split.*
*    * We will not remove the MAC header on packets being switched.*
** Ideas to be developed on ML:*
*    * [champion: Pascal] To avoid the RPL stretch, could we allow the PCE
to install routes.*
*    * [champions: Pascal,Xavi] 1-bit so 6tus either switches or hands off
to packet to routing layer. Several options: multicast MAC address,
IEEE802.15.4e IE, something in 6LoWPAN.*
*    * [champion: Alfredo] add timestamp to packet to influence forwarding
decision (most likely when routing, not switching, a packet)*
*    * [champion: Pascal] Dealing with 6LoWPAN fragment. To avoid
re-assembly at each hop: 6tus switching or 6LoWPAN switching? (probably a
combination)*
** Action items:*
*    * [Maria Rita, Alfredo, Pascal, Pouria] Set of slides on how to build
the simplest 6TSCH network.*

Minutes
-------

* [08.05] Meeting starts
   * [Pascal] Goal: How can be avoid the waste of BW. Side discussion:
Where do we place the excess bandwidth needed because of retries.
* [08.07] Logo Challenge
   * 15 votes so far.
   * Logo 2 a bit ahead of logo 3
   * URL on ML
   * Winner announced at next call
* Berlin Update
   * Thomas presents important dates slides
   * Pascal social event is on Tuesday, usually lots of fun
* 6lo
    * 6lowpan is closing
    * new ML for updates and other improvements
    * 6lowpan will hold interop in berlin
    * compression mechanisms
    * have not hear asked for a BoF
* [08.11] Multiplexing Tracks [Pascal]
    * Statistical mux
        * effect of queuing on priority
        * undeterministic flows: multiple flows arrive in router. Complex
router.
        * could 6tus do this sort of thing
        * can 6tus can have a statistical mux?
        * federates the cost of retries as allows slot reuse
        * how much of that we can to have on the 6tus sublayer?
        * won't expect that this will be simple.
        * [Thomas]
            * wireless is lossy in nature, retries are part of the actual
flow.
            * it is important that we consider retries part of the initial
flow.
            * building the track according to what is required, and use
another shared track for retries will make things very complicated.
            * suggest: pipe on the main track should reflect the
retransmissions (ETX). so reservation should take etx into account.
            * Errors does not translate to other hops, jitter translates to
next hops.
    * [8:17] Implicit vs explicit pipes [Thomas]
        * If each flow is a dedicated pipe, when there is no traffic, the
receivers idle listens for each flow. This might incur more energy.
        * When we are multiplexing tracks, implicit label does not identify
flow, and Kris proposed to use the mac destination address as a dissector.
        * Idea: install a track and assume it is deterministic. One can
always use routed cells.
        * [Pascal] We don't want to reinvent QoS in 6tus.
        * [Pascal] Routes are installed by RPL, would we let the PCE
install routes?
        * [Thomas] The PCE installs L2 resources. PCE can install other
cells so this can be used for non-switched routing.
        * Use 1 bit in 6LoWPAN header that tells whether explicit of
implicit label?
        * In order to be able to distinguish between switched packets and
packets that have an special header we need some bit at L2 so the switching
component can decide to forward or to parse the header.
        * [Pascal] An alternative is to use multicast mac layer addresses.
        * Keep mac layer header in the label switched packets
        * Thomas ask for rough consensus between
            * Proposal 1: LS tracks are water tight pipes (deterministic)
            * Proposal 2: combine/multiples cells so we can optimize the
energy consumption.
            * we vote for proposal 1.
* [8:34] Explicit Labels [Alfredo]
    * Explicit label can contain TTL or a TS.
        * use it to drop packets on route if too old/late
        * change priority as a function of ttl
        * manage delay
    * How to make it optional?
        * how to distinguish a packet with/without header?
        * [Pascal] Even if jitter is accumulated in the track, at the other
side of the tunnel you know what packet it is so (worst case) you can know
if it is too late or delay is not guaranteed.
        * [Alfredo] Soft delay guarantees
        * Whether bot considering that for Label Switching, where the field
should live? L3 has this information.
        * Infomration is passed to L3,
        * It has to be somewhere between L2 and L3.
        * In conclusion:
            * Great idea. Be able to adjust when packet is routed.
            * Cannot be applied to label switching
            * Consider this for routing not for track based switching.
* [8:45] Forwarding Modes [Maria Rita]
    * IP Routing
        * different sublayers on the stack and showing how a packet flows.
        * x-y has a bundle of 2 cells
        * a packet flows through the network and goes up to L3 at each hop
so the next hop is determined by routing.
    * Track switching:
        * we can use 2 tracks and use label switching
        * in that case the packet is directly forwarded by 6tus
        * Some cells are colored but others can be used for other things,
so not all cells form part of the label switching path
    * 6LoWPAN fragments forwarding (
http://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-07
):
        * avoids fragment reassembly at each hop.
        * state installed in nodes by first fragments, fragments follow the
same track
        * datagram ID of each fragment is switched at each hop to play the
role of a label as in LS
        * we can switch at 6tus layer or at 6lowpan layer
* [8:59] bundle size and ETC
    * long term PDT stats can be used.
    * account for retransmissions on the schedule.
    * _No concerns from the people on the call_
* [09.00] Simplest TSCH draft
    * good and simple base
    * interop events
    * work out all the details
    * how do you join, how do you synch, what's in the EB
    * more complex scenarios can appear later
    * absolute simples tsch
    * hardcoded slotted aloha
    * [Tom] The best way to do this is take an example and go through it
completely to identify all the elements that you forgot about.
    * [Xavi] proposes to work on this
    * [Alfredo] proposes to work on this
    * [Maria Rita] proposes to work on this (by chat)
    * [Thomas] Could volunteers prepare a set of slides for the next call?