Re: [6tisch] Comments on draft-ietf-6tisch-msf-00

[Yasuyuki Tanaka <[e-mail]>]

Hi,

I have additional comments on the latest MSF:

* discussion: scheduling adaptation

MSF can adapts to traffic changes in the manner described in section 5.1. It
seems this mechanism doesn't work well under a heavy loaded situation.

After joining process, a joined node (child) has one autonomous cell to its
parent, which is the autonomous RX cell from the viewpoint of the parent. If the
network is inactive and the link quality is pretty good, the child can send a
frame over the autonomous cell anytime it wants. And, if it has always frames to
send, then the adaptation mechanism will determines to allocate additional
cells.

However, if there are many siblings of the child around and its network load is
high, frames sent by the child on the autonomous cell of the parent are likely
to be lost because of collisions. When the child has an un-acknowledged frame,
it has to perform the retransmission algorithm since the autonomous cell has the
SHARED bit on. A bad thing to the adaptation mechanism is that "NumCellsUsed" is
not incremented during the backoff wait, although "NumCellsPassed" is counted
up. As a result, the child cannot have additional (dedicated) cells here even
though it may have many cells in its TX queue.

It may be fine, by the way, since these frames in the TX queue will be sent
continuously thanks to the pending bit once the first frame is received
successfully by the parent. But, an additional dedicated cell is not allocated
in this case, anyway.

A simple solution is to increment "NumCellsUsed" during the backoff wait if it's
desirable to have a dedicated cell to the parent in such a case.

* trivial comment: channel to listen on for EBs

The pledge may not know in advance which channels are used in a network to
join. So, it'd be better to try a different frequency if it cannot receive any
EB for a while.

draft> 4.2.  Step 1 - Choosing Frequency
draft> 
draft>    When switched on, the pledge SHOULD randomly choose a frequency among
draft>    the available frequencies, and start listening for EBs on that
draft>    frequency.
draft> 
draft> 4.3.  Step 2 - Receiving EBs
draft> 
draft>    Upon receiving the first EB, the pledge SHOULD continue listening for
draft>    additional EBs to learn:

Best,
Yatch


On Aug 31, 2018, at 15:33, Yasuyuki Tanaka <[e-mail]> wrote:
> 
> Thank you, Simon and Xavi!
> 
> A couple of things:
> 
>>>> 'MUST' here sounds too strong... Some may want to use MSF with a base schedule
>>>> other than one defined RFC 8180 with full understands on implications by not
>>>> following RFC 8180. Then, I'd propose 'SHOULD'.
>>>> 
>>>> By the way, I'm not sure whether we can specify 'MUST implement' to a BCP
>>>> document or not.
>>> 
>>> MSF assumes the presence of the minimal cell, but might be able to run without the full RFC8180.
>>> Happy to hear what others think
>>> 
>> XV>> MSF needs at least one pre-existing cell in the schedule so a node can receive/send EBs and form/join into the network. To ensure this we enforce RFC8180.
> 
> If the minimal shared cell is only the dependency for MSF, it'd be much clearer to say that instead of saying, "MSF MUST implement RFC 8180". RFC 8180 defines far more things than having the minimal shared cell. And, it concerns 2.4 GHz O-QPSK PHY alone.
> 
>>>> * minor comment 6
>>>> 
>>>> What is Section 10, "Rule for Ordering Cells", for...? Why do we need this
>>>> section?
>>>> 
>>> I'll let other co-authors answer
>>> 
>> XV> I think this was though to handle pagination when the LIST command is received. This is, define what are the cells to return when a list command is requesting cells from a particular offset. 
> 
> I see; then, I'd like to have such explanation in Section 10 :-)
> 
>   https://tools.ietf.org/html/draft-ietf-6tisch-msf-00#section-10
> 
> Best,
> Yatch