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

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

Thanks Thomas and Nicola for your comments.

Yes, Nicola your explanation makes sense. And I do agree. We only need to make it clearer in the text.

Yes, Thomas, I agree we are referring to INCOMING bundles (from a node TO a neighbor). So maybe we can mention once that when referring to the bundle, we mean the incoming one.

About “freeing” cells, the idea was to avoid to delete and add cells several times. If we deal with L2 track in the feature, it may happen that cells are not needed for a given track, but they could for another. So by freeing them, they can use by the other track, without going through a deleting and adding process again, so I don’t know if we are really complicating or simplifying things…

Thank you!
Maria Rita


From: Nicola Accettura [mailto:[e-mail]]
Sent: Thursday, July 2, 2015 2:57 PM
To: Thomas Watteyne
Cc: Maria Rita PALATTELLA; [e-mail]
Subject: Re: [6tisch] REVIEW and COMMENTS on draft-dujovne-6tisch-on-the-fly

Maria Rita,

I've got a single additional comment, you can find it inline.
Nicola

2015-07-02 3:57 GMT-07:00 Thomas Watteyne <[e-mail]<mailto:[e-mail]>>:
Comment <tw>inline</tw>.

On Thu, Jul 2, 2015 at 12:55 PM, Maria Rita PALATTELLA <[e-mail]<mailto:[e-mail]>> wrote:
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?

You are right, there is an inconsistency in the terms used. I'll give an interpretation of what the text means.

WHEN is OTF triggered? It depends on the triggering event, which is implementation-dependant and out of scope (e.g., on a buffer overflow, or periodically, or every X packets received). The sentence on page 3 sec. 2 that you point out, I guess, referes to the triggering event.

Once triggered, OTF decides IF adding/deleting cells. In this sense, "when" stands for "if" in the abstract and in the other sentences referring to the outcome of OTF.
Does it make sense?
We have to clarify in the text, I agree.


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?

<tw>I believe a node only worries about scheduling cells TO its neighbor, and that cells are NOT bidirection. Of course, a node will receive requests from it neighbor (for incoming cells), but doesn't trigger those.</tw>

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.

<tw>I'm afraid I don't catch the subtlety here. I would just add/delete cells and not try to recycle them. Seems like a complicated optimization with no clear quantified benefits.</tw>

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.

<tw>Agreed, probably a point to raise during the WG meeting?</tw>

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



_______________________________________________
6tisch mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/6tisch


_______________________________________________
6tisch mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/6tisch