Comment <tw>inline</tw>. On Thu, Jul 2, 2015 at 12:55 PM, Maria Rita PALATTELLA < [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? > > > > 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] > https://www.ietf.org/mailman/listinfo/6tisch > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
