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

[Nicola Accettura <[e-mail]>]

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]>:

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