Thomas, if I consider the L3 link among node A and node B, we will have Incoming bundle (macA, macB, NULLT) and Outgoing boundle (macB, macA, NULLT). So, in our case, we care of the incoming L3 bundle, between A and B.
If we look at L2, and we consider the segment X-A-B, in node A I will have two bundle: Incoming (macX, macA, trackL2), and outgoing (macA, macB, trackL2). So maybe this is where the confusion can come from. Right? Maria Rita From: [email protected] [mailto:[email protected]] On Behalf Of Thomas Watteyne Sent: Friday, July 3, 2015 9:14 AM To: Maria Rita PALATTELLA Cc: Nicola Accettura; [email protected] Subject: Re: [6tisch] REVIEW and COMMENTS on draft-dujovne-6tisch-on-the-fly Maria Rita, Did you mean incoming or outgoing? Thomas On Friday, July 3, 2015, Maria Rita PALATTELLA <[email protected]<mailto:[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
