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

Comment <tw>inline</tw>.

On Thu, Jul 2, 2015 at 12:55 PM, Maria Rita PALATTELLA <
maria-rita.palattella@uni.lu> 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
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>