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

[Thomas Watteyne <[e-mail]>]

Maria Rita,
Did you mean incoming or outgoing?
Thomas

On Friday, July 3, 2015, Maria Rita PALATTELLA <[e-mail]>
wrote:

>  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]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>]
> *Sent:* Thursday, July 2, 2015 2:57 PM
> *To:* Thomas Watteyne
> *Cc:* Maria Rita PALATTELLA; [e-mail]
> <javascript:_e(%7B%7D,'cvml','[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]
> <javascript:_e(%7B%7D,'cvml','[e-mail]');>>:
>
>  Comment <tw>inline</tw>.
>
>
>
> On Thu, Jul 2, 2015 at 12:55 PM, Maria Rita PALATTELLA <
> [e-mail]
> <javascript:_e(%7B%7D,'cvml','[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] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> [e-mail] <javascript:_e(%7B%7D,'cvml','[e-mail]');>
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
>