[6tisch] REVIEW and COMMENTS on draft-dujovne-6tisch-on-the-fly

[Maria Rita PALATTELLA <[e-mail]>]

Hi all,
I have reviewed the last version(v5) of the  OTF draft.

The draft mainly looks good, but I have some “almost” minor comments.

I think there is an inconsistence to be fixed.
In the abstract and at pag. 4 we state that OTF  (and the allocation policy) determines/decides WHEN to reserve/delete soft cells in the schedule.
But in sec. 2, pag. 3, we state that the algorithm which decides WHEN to add/delete soft cells is out of scope.
I think this last sentence isn’t correct, because OTF actually determines WHEN, based on the values of the thresholds. What is not defined, and out of scope, is the actual NUMBER of cells to be added or deleted.
Am I wrong?

Another thing to be clarified is the allocation of cells on the best effort L3 bundle.
Actually, when we talk of a L3 track, and we look at the bandwidth on a L3 link, between two neighbors, we have 2 bundles associated to that link, one incoming, and one outgoing.
When we add cells, are we referring to the INCOMING bundle, or are we supposed to add the cells on both bundles? Pascal? How does it work?

I was also wondering that it may be useful in the future do add a 6top command that allows to “FREE” a cell. Instead of deleting cells from the best effort track.
In fact, if we check the scheduled BWD per L2 track, then it may happen that we don’t need cells for the traffic on that track, but we may need it for other tracks, using the same L3 link.
In that case, I wouldn’t delete the cells from the L3 bundle.

In line with this, I think we should plan to work on how OTF will deal with L2 tracks, and also with chunks appropriation. But now it is too short for this IETF meeting, we may discuss while we are there.

Moreover, I think in sec. 7, when we define the (default) bandwidth estimation algorithm, as we did for the description of the events, we should make clear the link with the OTF allocation policy, and thus, between incoming, outgoing traffic, scheduled cells, reserved cells, etc.
In the way it is described, it is not straightforward to understand such link.

Here are some editorial changes:

Legend **xx** -> ADD *X* -> delete


1)      Check if best effort track is identified by TrackID = 00, or = NULLT

2)      In OTFTHRESHLOW/HIGH definition -> out of **OTF** scope

3)      Fig. 1 label: …. For triggering **6top** add/remove **soft cell** command

4)      When both OTFTHRESHLOW and OTFTHRESHHIGH **are** equal **to**  0, any discrepancy …….

5)      Other values for the thresholds *values* **, different from 0,**  reduce the  number of triggered 6top negotiations.

6)      Sec 6,  before listing the parameters: ** We define the following parameters:**

7)      Sec. 7, **The steps of the ** default bandwidth estimation algorithm, running over a parent node, **are listed hereafter:**

8)      Reference to be fixed: I-D.ietf-6TiSCH-tsch -> now RFC7554

Please note that my review doesn’t take into account the last discussion on the ML about the draft. I need to couch up with the emails. Thanks!

Maria Rita