Subject: [6tisch] minute ad-hoc meeting SF0, 13 October 2015

From: Thomas Watteyne <[email-masked]>
Date: Tue, 13 Oct 2015 13:54:00 +0200

In an effort to prepare the re-factoring of
https://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-06 into what
will become the SF0, we had an ad-hoc meeting with the authors of that
draft.

Minutes below.

Thomas

----

Minutes, 13 October 2015, ad-hoc meeting SF0

Note: times in CET

NO recording was made, since this is an ad-hoc (no WG interim) meeting.
Present

   - Diego Dujovne
   - Nicola Accettura
   - Alfredo Grieco
   - Maria Rita Palattella
   - Thomas Watteyne

action items

   - *Diego* to rename repo, create skeleton of SF0 document, and assign
   tasks
   - *Nicola* to write down exact formula for calculating the timeout
   - *Nicola* and *Thomas* to be available to write parts of the document
   - *Maria Rita* and *Alfredo* to proof-read documents before publication

goal

discuss how to re-factor
https://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-06 into the SF0
draft, so fits nicely on top of
https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-02
minutes

   - meeting starts at 11.00 AM
   - Intro
      - *Thomas* details the idea of 6P+SF0
      - *Maria Rita*: Define mechanism to select the cell. Give basic rule
      on how to pick the cell. For example, how to pick the cells. We were
      relying on the monitoring already there, but now it should be done by the
      SF0.
      - *Thomas* agreed. Cells could be selected randomly. We need to align
      the two drafts. Look at what is written in the sublayer draft. Sec. 4.2
      lists what a SF must do.
      - *Maria Rita*: what is the timeout?
      - *Thomas* timeout value depends on the RTT between neighbors. We can
      put a high value, nevertheless the scheduler function knows the cells
      already with the neighbor, so it may calculate a timeout value.
      - *Maria Rita*: what is the container field?
      - *Thomas* allows us to use multiple SFs on the same node, and use
      them on different slotframes/chunks.
      - *Maria Rita*: what is a cell identified with?
      - *Thomas* 4-byte cell identifier. Container generic. e.g. always
      from container 0, or the container is a set of flags, or the
container can
      be the chunk number.
      - *Nicola* The cell selection a request a block of cells, so the
      receiver can choose the channel offset. Maybe identified by
boundaries (set
      of cells) for allocating one or more cells. Indicate many: the
whole block
      offset can be allocated, but also the channel offset.
      - *Thomas* great idea, but maybe more an extension for the simple
      mechanism, with cell boundaries. We can evolve to a new version.
So we can
      say that two cells can mean the beginning and the end.
      - *Nicola* both must understand the same meaning on both ends. If a
      bigger set of cells is proposed, there is a higher chance to have a
      successful allocation. All the available cells on the transmitter side.
      - *Thomas* agreed that in that case it's more efficient to encode it
      as a range rather than a list of discrete cells. But maintains
that this is
      an optimization for cases where the schedule is very dense
      - *Nicola* agrees that better for other scheduling functions apart
      from SF0. Even just saying the channel offset. Slot offset may generate
      more conflicts than channel offset.
      - *Thomas* We are not aiming to put the complete list of cells. Not
      exhaustive. If the first don't work, try others. We are talking of the
      probability to choose from the ones proposed, which is very high, given
      that schedule is mostly empty. Some optimizations can be proposed in case
      the schedule is filled. What you describe is a more efficient way of
      describing a range of cells. This can be described using by using what is
      specified on 3.1.5 of the sublayer draft.
   - Go over the requirements for an SF in
   https://tools.ietf.org/html/draft-wang-6tisch-6top-sublayer-02#section-4.2
      - MUST specify an identifier for that 6OF.
         - IANA_SF0_ID. In IANA Consideration section, ask IANA to allocate
         a number. We recommend "0".
      - MUST specify a set of rules for a node to decide when to add one or
      more cells to a neighbor.
         - contents of
         https://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-06#section-2
          and
         https://tools.ietf.org/html/draft-dujovne-6tisch-on-the-fly-06#section-7
          combined
         - *Maria Rita* we can distinguish 2 phases:
            - estimation (section 7)
            - based on estimation, comparison and decide to ADD/DELETE
            (section 2)
         - *Nicola*: issue: exchange add/remove cells
         - *Thomas* creates an issue on the OTF issue tracker.
      - MUST specify a set of rules for a node to decide when to delete one
      or more cells to a neighbor.
         - same as above
      - MUST specify a value for the timeout, or a rule to calculate it.
         - *Nicola* describes a formula which depends on backoff algorithm
         - Action item: *Nicola* to write down exact formula for
         calculating the timeout
      - MUST specify a meaning for the "Container" field in the 6P ADD
      Request.
         - value in the container field is the slotframe handle to pick from
         - we RECOMMEND to announced as a second slotframe in the EB, with
         NO slots
      - MUST specify the rule for selecting the cells (including their
      number) to add to the CellList field in the 6P ADD Request.
         - *Nicola*: More priority to the 6OF traffic? Possible overlap of
         Minimal with the 6OF slotframe.
         - *Thomas*: Possible deadlock if higher priority given to 6OF.
         - *Nicola*: Multicast traffic-related higher priority.
         - *Maria Rita*: There is no mechanism to allow 6OF change
         priorities.
         - *Thomas*: Slotframe handle 0 for Minimal and Slotframe 1 for 6OF.
         - A node SHOULD NOT select cells for the candidate list which
         overlap with cells scheduled in the minimal slotframe
         - We RECOMMEND that the length of the OTF slotframe is an integer
         multiple of the length of the minimal slotframe
         - *Thomas* creates an issue on the 6top-sublayer draft: remove
         "(including their number)":
            - OLD: MUST specify the rule for selecting the cells (including
            their number) to add to the CellList field in the 6P ADD Request.
            - NEW: MUST specify the rule for selecting the cells to add to
            the CellList field in the 6P ADD Request.
         - MUST specify the rule for verifying which cells from the
      CellList it can add to it schedule.
         - go through the candidate list in order. Pick the first NumCells
         cells which are not used in the current schedule.
      - MUST specify what to do after an error has occurred
         - either the node sent a 6P Response with an error code, or
         received one
         - RC_SUCCESS but no cells in the CellList of the response: means
         neighbor receive request, but no cells in the CellList are
usable. In that
         case, retry immediate with a different celllist or a new
random set if not
         enough RAM.
         - RC_ERR_VER: do not try again, blacklist the neighbor if RAM
         permits.
         - RC_ERR_6OFID: do not try again, blacklist the neighbor if RAM
         permits
         - RC_ERR_NORESOURCES wait for timeout and retry
         - RC_ERR_BUSY issue a RESET (new command needed)
      - SHOULD clearly state the application domain the 6OF is created for.
         - SF0 is generic, not optimized for particular application.
      - SHOULD contain examples which highlight normal and error scenarios.
         - *Nicola* to provide a diagram which shows when/why 3-way
         handshake is used.
      - SHOULD contain a performance evaluation of the scheme, possibly
      through references to external documents.
      - the SF MUST specify the behavior of a mote when it boots
         - if the has non-volatile and have a schedule, MUST verify with
         COUNT and MAY versify or more LIST to verify coherence
         - if not volatile, MAY do a COUNT, and either issue a CLEAR or ask
         LIST explicitly
      - changes to draft-sublayer
      - RC missing
         - RC_RESET: sent by receiving node when internal server error
      - commands missing
         - CLEAR: remove every cell from me
         - COUNT: tell me how many cells from me are in your schedule
         - LIST: ask a neighbor list the cells you have to it. Include an
         start index. sorted by slotoffset first/channeloffset second
      - relocation
      - add a section about the idea of maintaining stats and comparing
      PDRs between different cells, but leave the threshold as implementation
      specific
   - meeting ends at 12.50 PM