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