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

From: Maria Rita PALATTELLA <[email-masked]>
Date: Thu, 2 Jul 2015 10:55:16 +0000

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?

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.

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.

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

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 2 Jul 2015 12:57:41 +0200

Comment <tw>inline</tw>.

On Thu, Jul 2, 2015 at 12:55 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

> 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.
>
> 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?
>
>
>
> 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.
>

<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.
>
> Legend **xx** -> ADD **X** -> delete
>
>
>
> 5)      Other values for the thresholds **values** **, different from
> 0,**  reduce the  number of triggered 6top negotiations.
>
> 7)      Sec. 7, **The steps of the ** default bandwidth estimation
> algorithm, running over a parent node, **are listed hereafter:**
>
> 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-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Nicola Accettura <[email-masked]>
Date: Thu, 2 Jul 2015 05:57:14 -0700

Maria Rita,

I've got a single additional comment, you can find it inline.

Nicola

>> of scope, is the actual NUMBER of cells to be added or deleted.
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.

>> 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.
>>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 3 Jul 2015 07:09:05 +0000

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-masked]]
Sent: Thursday, July 2, 2015 2:57 PM
To: Thomas Watteyne
Cc: Maria Rita PALATTELLA; [email-masked]
Subject: Re: [6tisch] REVIEW and COMMENTS on draft-dujovne-6tisch-on-the-fly

Maria Rita,

2015-07-02 3:57 GMT-07:00 Thomas Watteyne <[email-masked]<mailto:[email-masked]>>:
Comment <tw>inline</tw>.

On Thu, Jul 2, 2015 at 12:55 PM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,
I have reviewed the last version(v5) of the  OTF draft.

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.

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

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

Maria Rita

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 3 Jul 2015 09:14:26 +0200

Maria Rita,
Did you mean incoming or outgoing?
Thomas

On Friday, July 3, 2015, Maria Rita PALATTELLA <[email-masked]>
wrote:

> 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-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>]
> *Sent:* Thursday, July 2, 2015 2:57 PM
> *To:* Thomas Watteyne
> *Cc:* Maria Rita PALATTELLA; [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> *Subject:* Re: [6tisch] REVIEW and COMMENTS on
> draft-dujovne-6tisch-on-the-fly
>
>
>
> Maria Rita,
>
>
> 2015-07-02 3:57 GMT-07:00 Thomas Watteyne <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>:
>
>  Comment <tw>inline</tw>.
>
>
>
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>  Hi all,
>
> 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?
>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 3 Jul 2015 07:21:26 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Friday, July 3, 2015 9:14 AM
To: Maria Rita PALATTELLA
Cc: Nicola Accettura; [email-masked]
Subject: Re: [6tisch] REVIEW and COMMENTS on draft-dujovne-6tisch-on-the-fly

Maria Rita,

On Friday, July 3, 2015, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Thomas and Nicola for your comments.

Thank you!
Maria Rita

From: Nicola Accettura [mailto:[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>]
Sent: Thursday, July 2, 2015 2:57 PM
To: Thomas Watteyne
Cc: Maria Rita PALATTELLA; [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
Subject: Re: [6tisch] REVIEW and COMMENTS on draft-dujovne-6tisch-on-the-fly

Maria Rita,

2015-07-02 3:57 GMT-07:00 Thomas Watteyne <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>:
Comment <tw>inline</tw>.

On Thu, Jul 2, 2015 at 12:55 PM, Maria Rita PALATTELLA <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
Hi all,
I have reviewed the last version(v5) of the  OTF draft.

Maria Rita

_______________________________________________
6tisch mailing list
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
https://www.ietf.org/mailman/listinfo/6tisch

_______________________________________________
6tisch mailing list
[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
https://www.ietf.org/mailman/listinfo/6tisch

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 3 Jul 2015 15:24:52 +0000

Thomas, all,
Sorry for having created confusion. Now let’s try to make things clear for everyone (for me too!).

Let’s consider a track, A->B->C->D.
Along the track, for each hop, a bundle of cells set to RX is uniquely paired to a bundle of cells set to TX.
If we consider node B, then the INCOMING BUNDLE (macA, macB, trackID) [with RX cells for B] is paired to the OUTGOING bundle (macB, macC, trackID), [with TX cells for B].
So, with OTF, we will add/remove TX cells for a given node, and we will deal with OUTGOING bundle.

I was thinking at the L3 link’s representation in term of bundles, but actually we have to look at the L2, even though we are considering the best effort track.

Sorry again! Thanks!
Maria Rita

From: 6tisch [mailto:[email-masked]] On Behalf Of Maria Rita PALATTELLA
Sent: Friday, July 3, 2015 9:21 AM
To: Thomas Watteyne
Cc: Nicola Accettura; [email-masked]
Subject: Re: [6tisch] REVIEW and COMMENTS on draft-dujovne-6tisch-on-the-fly

Maria Rita

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Friday, July 3, 2015 9:14 AM
To: Maria Rita PALATTELLA
Cc: Nicola Accettura; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] REVIEW and COMMENTS on draft-dujovne-6tisch-on-the-fly

Maria Rita,

Thank you!
Maria Rita

Maria Rita,

Maria Rita