Subject: Re: [6tisch] My adoption-time review of SFO

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 13 May 2016 12:08:03 -0300

Dear all,
            During today's webex call, I presented a slide where
the comments below were going to be addressed on the next
version of the draft.
            However, I raised the point about:

Ø  4.  Rules for CellList

Why is this here? Which cell are allocated is not SF0 ‘s business, is it?
OTOH, the semantics of the ADD that is mentioned should be somewhere, and I
think, in this document.

-> This section is recommended by the 6top-protocol draft, and AFAIK it
defines which cells are offered and which are selected for allocation.

Ø  7.  Node Behavior at Boot

Again this is describing 6P not SF0 behavior. Note that the clear should be
done at link up in case

-> This section is also recommended by the 6top-protocol draft, and it
should include any type of pre-configuration and expected initial state on
the SF.
-> From the comment from Pascal on today's webex: "What if a node has a big
storage and it can keep all configuration after a crash?" The SF can
use that info to reconstruct all the configuration and recover instead of
issuing a clear command. However, there must be a timeout period for
recover;
if this timeout expires, then all the cells from the crashed node shall be
released.

Rules for CellList and Node Behaviour at boot are
recommended on Sec. 5.3 of draft-ietf-6tisch-6top-
protocol-00

2016-04-18 13:48 GMT-03:00 Pascal Thubert (pthubert) <[email-masked]>:

> Dear authors:
>
>
>
> Please find my review of the SF0 draft; but since last call is pending
> please do not make **any** changes till after draft-ietf-*- 00 is
> published.
>
>
>
>
>
>
>
> Ø   This document addresses the requirements for a scheduling function
>
>    listed in [I-D.wang-6tisch-6top-sublayer <https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#ref-I-D.wang-6tisch-6top-sublayer>], Section 4.2, and follows
>
>    the recommended outline from Section 4.3 <https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#section-4.3>.
>
>
>
> I would expect that this doc is the reference for SF and is the one that
> requests the creation of the SF registry by IANA (text to be added in the
> IANA section).
>
> This reference to sublayer should go away since we are not promoting the
> draft at the moment – or should we be doing so?
>
>
>
>
>
>
>
> Ø
>
> Ø  3.1.  SF0 Triggering Events
>
> Ø
>
> Ø     We RECOMMEND SF0 to be triggered at least by the following events:
>
>
>
> The term ‘We’ is probably inappropriate. Better formulate this like “ It
> is RECOMMENDED that…”
>
>
>
> Also shouldn’t there be an event when:
>
>
>
> -        Connectivity to the neighbor is lost. A L3 Link down event
> should free up resources. The question for 6P is how both sides agree at
> the same time that the link is down.
>
> -        A threshold of unused time slots is reached so they should be
> freed
>
>
>
>
>
> Ø   6.  If the RAB is less than the Minimum Remaining Bandwidth (MRB),
>
>        Add MRB to the NOB: NOB=NOB+MRB
>
>
>
> Shouldn’t this be
>
>        NOB=MRB
>
>
>
>
>
>
>
> Ø  4.  Rules for CellList
>
>
>
> Why is this here? Which cell are allocated is not SF0 ‘s business, is it?
> OTOH, the semantics of the ADD that is mentioned should be somewhere, and I
> think, in this document.
>
>
>
>
>
> Ø  7.  Node Behavior at Boot
>
>
>
> Again this is describing 6P not SF0 behavior. Note that the clear should
> be done at link up in case
>
>
>
>
>
>
>
>
>
> Ø  11.  Examples
>
> Ø
>
> Ø     TODO
>
> Ø
>
> Ø  12.  Implementation Status
>
>
>
> These sections probably belong to annexes
>
>
>
>
>
> Cheers,
>
>
>
> Pascal
>
>
>
>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl
(56 2) 676 8125

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 May 2016 15:50:17 +0000

Hell Diego,

My point is that a SF should operate on a number of units of transmissions,  which happen to be cells in our case.
SF should indicate to 6top that there is a need to change for more of less of these units.
But the fact that one of these units is mapped to a particular slot offset / channel offset should not be its business. I see it as a layer violation…
What if for instance the SF is in the root? Should it really manage down to the cell?

Pascal

From: Prof. Diego Dujovne [mailto:[email-masked]]
Sent: vendredi 13 mai 2016 17:08
To: Pascal Thubert (pthubert) <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [6tisch] My adoption-time review of SFO

Dear all,
            During today's webex call, I presented a slide where
the comments below were going to be addressed on the next
version of the draft.
            However, I raised the point about:

>  4.  Rules for CellList

Why is this here? Which cell are allocated is not SF0 ‘s business, is it? OTOH, the semantics of the ADD that is mentioned should be somewhere, and I think, in this document.

-> This section is recommended by the 6top-protocol draft, and AFAIK it defines which cells are offered and which are selected for allocation.

>  7.  Node Behavior at Boot

Again this is describing 6P not SF0 behavior. Note that the clear should be done at link up in case

-> This section is also recommended by the 6top-protocol draft, and it should include any type of pre-configuration and expected initial state on the SF.
-> From the comment from Pascal on today's webex: "What if a node has a big storage and it can keep all configuration after a crash?" The SF can
use that info to reconstruct all the configuration and recover instead of issuing a clear command. However, there must be a timeout period for recover;
if this timeout expires, then all the cells from the crashed node shall be released.

2016-04-18 13:48 GMT-03:00 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
Dear authors:

Please find my review of the SF0 draft; but since last call is pending please do not make *any* changes till after draft-ietf-*- 00 is published.

>   This document addresses the requirements for a scheduling function

   listed in [I-D.wang-6tisch-6top-sublayer<https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#ref-I-D.wang-6tisch-6top-sublayer>], Section 4.2, and follows

   the recommended outline from Section 4.3<https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#section-4.3>.

I would expect that this doc is the reference for SF and is the one that requests the creation of the SF registry by IANA (text to be added in the IANA section).
This reference to sublayer should go away since we are not promoting the draft at the moment – or should we be doing so?

>  3.1.  SF0 Triggering Events

>     We RECOMMEND SF0 to be triggered at least by the following events:

The term ‘We’ is probably inappropriate. Better formulate this like “ It is RECOMMENDED that…”

-        Connectivity to the neighbor is lost. A L3 Link down event should free up resources. The question for 6P is how both sides agree at the same time that the link is down.

-        A threshold of unused time slots is reached so they should be freed

>   6.  If the RAB is less than the Minimum Remaining Bandwidth (MRB),

Shouldn’t this be

       NOB=MRB

>  4.  Rules for CellList

Why is this here? Which cell are allocated is not SF0 ‘s business, is it? OTOH, the semantics of the ADD that is mentioned should be somewhere, and I think, in this document.

>  7.  Node Behavior at Boot

Again this is describing 6P not SF0 behavior. Note that the clear should be done at link up in case

>  11.  Examples

>     TODO

>  12.  Implementation Status

Cheers,

Pascal

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

--
DIEGO DUJOVNE
Académico Escuela de Ingeniería en Informática y Telecomunicaciones
Facultad de Ingeniería UDP
www.ingenieria.udp.cl<http://www.ingenieria.udp.cl>
(56 2) 676 8125

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 13 May 2016 14:34:55 -0300

Pascal,
           The question here is who is doing cell accounting.
AFAIK, 6P had to guarantee transactions and SF had to
do the accounting by directly managing the cells by their
identification. This is explained (at least) on the example
from Figure 4, section 4.1.1, step 1, on page 6 of the
6top-protocol draft:

 1.  The SF running on node A selects 3 candidate cells.

So the SF decides which are the candidates for the CellList.
On the same example, on step 3:

3.  The SF running on node B selects 2 of the 3 cells in the CellList
       of the 6P ADD Request.  Node B sends back a 6P Response to node
       A, indicating the cells it selected.

So the SF on the other end selects which of the candidates should be chosen.

This process is better explained on section 4.3.6: Adding cells.

Now, suppose the SF does the accounting only
on the amount of cells per bundle (assuming a bundle is
a one-way link against a neighbour) and 6P manages
the cell IDs:
The conflict here comes from the relocation
algorithm, which keeps statistics on individual (and identified)
cells to relocate them in case the PDR drops below a certain
threshold.
According to the 6top-protocol draft, this is a task which
corresponds to the SF too.

Furthermore, SFs are part of the 6top protocol and not another
layer, so there is theoretically no layer violation there.

What do you think?

Regards,

                              Diego

2016-05-13 12:50 GMT-03:00 Pascal Thubert (pthubert) <[email-masked]>:

> Hell Diego,
>
>
>
> My point is that a SF should operate on a number of units of
> transmissions,  which happen to be cells in our case.
>
> But the fact that one of these units is mapped to a particular slot offset
> / channel offset should not be its business. I see it as a layer violation…
>
> *From:* Prof. Diego Dujovne [mailto:[email-masked]]
> *Sent:* vendredi 13 mai 2016 17:08
> *To:* Pascal Thubert (pthubert) <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
> *Subject:* Re: [6tisch] My adoption-time review of SFO
>
>
>
> Dear all,
>
> -> From the comment from Pascal on today's webex: "What if a node has a
> big storage and it can keep all configuration after a crash?" The SF can
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 13 May 2016 17:44:40 +0000

Hello Diego:

Thanks for this great argumentation. I agree that you are following the 6p design but disagree with that design in the first place.

I see value in a clear layer separation where the TSCH specifics are separated from the bandwidth calculations.

We could also see the functional group that is cell dependent and is not covered by 6P as another layer between the 2. That layer should be separated from SF and can be common between multiple SFs

Regards,

Pascal

Le 13 mai 2016 à 19:35, Prof. Diego Dujovne <[email-masked]<mailto:[email-masked]>> a écrit :

Pascal,

What do you think?

Regards,

                              Diego

2016-05-13 12:50 GMT-03:00 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
Hell Diego,

Pascal

From: Prof. Diego Dujovne [mailto:[email-masked]<mailto:[email-masked]>]
Sent: vendredi 13 mai 2016 17:08
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] My adoption-time review of SFO

Dear all,

Shouldn’t this be

       NOB=MRB

Cheers,

Pascal

---

From: "S.V.R.Anand" <[email-masked]>
Date: Thu, 19 May 2016 11:46:31 +0530

Hi Pascal,

I agree with your view. We certainly seem to require a service sub-layer 
that
provides link layer abstraction by offering ways of obtaining links with
desired properties that the user might want.

For instance, the user might want to ask this sub-layer for a provision of
desired number of links being made available at certain time intervals. The
time intervals can be specified, say, in terms of delay bounds. One can use
this link layer feature for several possible use cases, including (i) 
meeting
delay requirements at coarse or fine grain level (ii) power savings (iii)
improving data aggregation and so forth. The mapping of this requirement to
precise cell management functionality will then be handled by the lower 
layer
6P and SF mechanisms.

I am not sure how we can fit the above sub-layer in the current scheme of
things. Let me know if I am making sense.

Anand

On Friday 13 May 2016 09:20 PM, Pascal Thubert (pthubert) wrote:
> But the fact that one of these units is mapped to a particular slot 
> offset / channel offset should not be its business. I see it as a 
> layer violation…
>
> *From:*Prof. Diego Dujovne [mailto:[email-masked]]
> Ø4.  Rules for CellList
> Why is this here? Which cell are allocated is not SF0 ‘s business, is 
> it? OTOH, the semantics of the ADD that is mentioned should be 
> somewhere, and I think, in this document.
>
> -> This section is recommended by the 6top-protocol draft, and AFAIK 
> it defines which cells are offered and which are selected for allocation.
>
> Ø7.  Node Behavior at Boot
>
> should include any type of pre-configuration and expected initial 
> state on the SF.
>
> -> From the comment from Pascal on today's webex: "What if a node has 
> a big storage and it can keep all configuration after a crash?" The SF can
>
> use that info to reconstruct all the configuration and recover instead 
> of issuing a clear command. However, there must be a timeout period 
> for recover;
> 2016-04-18 13:48 GMT-03:00 Pascal Thubert (pthubert) 
> <[email-masked] <mailto:[email-masked]>>:
>
>     Dear authors:
>
>     Please find my review of the SF0 draft; but since last call is
>     pending please do not make **any** changes till after
>     draft-ietf-*- 00 is published.
>
>       
>
>         listed in [I-D.wang-6tisch-6top-sublayer
>     <https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#ref-I-D.wang-6tisch-6top-sublayer>], Section 4.2, and follows
>
>         the recommended outline fromSection 4.3
>     <https://tools.ietf.org/html/draft-dujovne-6tisch-6top-sf0-01#section-4.3>.
>
>     I would expect that this doc is the reference for SF and is the
>     one that requests the creation of the SF registry by IANA (text to
>     be added in the IANA section).
>
>     This reference to sublayer should go away since we are not
>     promoting the draft at the moment – or should we be doing so?
>
>     Ø
>
>     Ø3.1.  SF0 Triggering Events
>
>     Ø
>
>     -Connectivity to the neighbor is lost. A L3 Link down event should
>     free up resources. The question for 6P is how both sides agree at
>     -A threshold of unused time slots is reached so they should be freed
>
>     Ø4.  Rules for CellList
>     Why is this here? Which cell are allocated is not SF0 ‘s business,
>     is it? OTOH, the semantics of the ADD that is mentioned should be
>     somewhere, and I think, in this document.
>
>     Ø7.  Node Behavior at Boot
>
>     Ø11.  Examples
>     Ø12.  Implementation Status
>
>     [email-masked] <mailto:[email-masked]>
> www.ingenieria.udp.cl <http://www.ingenieria.udp.cl>
> (56 2) 676 8125
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 19 May 2016 12:48:33 +0000

I like this view, Anand.

Can we achieve that without getting complex?

Pascal

From: S.V.R.Anand [mailto:[email-masked]]
Sent: jeudi 19 mai 2016 08:17
To: Pascal Thubert (pthubert) <[email-masked]>; Prof. Diego Dujovne <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [6tisch] My adoption-time review of SFO

Hi Pascal,

I agree with your view. We certainly seem to require a service sub-layer that
provides link layer abstraction by offering ways of obtaining links with
desired properties that the user might want.

For instance, the user might want to ask this sub-layer for a provision of
desired number of links being made available at certain time intervals. The
time intervals can be specified, say, in terms of delay bounds. One can use
this link layer feature for several possible use cases, including (i) meeting
delay requirements at coarse or fine grain level (ii) power savings (iii)
improving data aggregation and so forth. The mapping of this requirement to
precise cell management functionality will then be handled by the lower layer
6P and SF mechanisms.

Anand

My point is that a SF should operate on a number of units of transmissions,  which happen to be cells in our case.
SF should indicate to 6top that there is a need to change for more of less of these units.
But the fact that one of these units is mapped to a particular slot offset / channel offset should not be its business. I see it as a layer violation...
What if for instance the SF is in the root? Should it really manage down to the cell?

Pascal

To: Pascal Thubert (pthubert) <[email-masked]><mailto:[email-masked]>

Dear all,

>  4.  Rules for CellList

Why is this here? Which cell are allocated is not SF0 's business, is it? OTOH, the semantics of the ADD that is mentioned should be somewhere, and I think, in this document.

I would expect that this doc is the reference for SF and is the one that requests the creation of the SF registry by IANA (text to be added in the IANA section).
This reference to sublayer should go away since we are not promoting the draft at the moment - or should we be doing so?

>     We RECOMMEND SF0 to be triggered at least by the following events:

The term 'We' is probably inappropriate. Better formulate this like " It is RECOMMENDED that..."

Also shouldn't there be an event when:

Shouldn't this be

       NOB=MRB

>  4.  Rules for CellList

Why is this here? Which cell are allocated is not SF0 's business, is it? OTOH, the semantics of the ADD that is mentioned should be somewhere, and I think, in this document.

Cheers,

Pascal

6tisch mailing list

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Thu, 19 May 2016 10:39:48 -0300

Pascal, Anand:
                        What I would propose is SF1 for this purpose.
Regards,

                                      Diego

2016-05-19 8:48 GMT-04:00 Pascal Thubert (pthubert) <[email-masked]>:

> *From:* S.V.R.Anand [mailto:[email-masked]]
> *Sent:* jeudi 19 mai 2016 08:17
> *To:* Pascal Thubert (pthubert) <[email-masked]>; Prof. Diego Dujovne
> <[email-masked]>
> *Cc:* [email-masked]; [email-masked]
>
> *From:* Prof. Diego Dujovne [mailto:[email-masked]
> <[email-masked]>]
> *To:* Pascal Thubert (pthubert) <[email-masked]> <[email-masked]>

---

From: "Satish Anamalamudi (Satish Anamalamudi)" <[email-masked]>
Date: Fri, 20 May 2016 03:05:46 +0000

Hello everyone,

It’s good to manage the cell information<slotoffset, channeloffset> in a separate module(namely “tisch cell management”) instead of naming it as “SF1”.  In the future, probably more SFx may be developed. In that case, Cell management module can provide the cell information to specific Scheduling Function (SFx).

SFx naming will be good to trigger scheduling functionalities for different traffic flows. If we make use of SFx extension for cell information then it may be confusing with traffic flows in the future.
What do you think ?

With Regards,
Satish.
From: 6tisch [mailto:[email-masked]] On Behalf Of Prof. Diego Dujovne
Sent: 2016年5月19日 21:40
To: Pascal Thubert (pthubert)
Cc: [email-masked]; S.V.R.Anand; [email-masked]
Subject: Re: [6tisch] My adoption-time review of SFO

Pascal, Anand:

2016-05-19 8:48 GMT-04:00 Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>:
I like this view, Anand.

Pascal

From: S.V.R.Anand [mailto:[email-masked]<mailto:[email-masked]>]
Sent: jeudi 19 mai 2016 08:17
To: Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>>; Prof. Diego Dujovne <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>

Hi Pascal,

Anand

Pascal

Dear all,

Shouldn’t this be

       NOB=MRB

Cheers,

Pascal

6tisch mailing list

---

From: "S.V.R.Anand" <[email-masked]>
Date: Fri, 20 May 2016 11:10:03 +0530

Hi Satish,

Yes, I agree with your point!

As Pascal remarked in response to my mail, we need to come up with an 
approach that is less complex.

Anand

On Friday 20 May 2016 08:35 AM, Satish Anamalamudi (Satish Anamalamudi) 
wrote:
>
> Hello everyone,
>
> It’s good to manage the cell information<slotoffset, channeloffset> in 
> a separate module(namely “tisch cell management”) instead of naming it 
> as “SF1”.  In the future, probably more SFx may be developed. In that 
> case, Cell management module can provide the cell information to 
> specific Scheduling Function (SFx).
>
> SFx naming will be good to trigger scheduling functionalities for 
> different traffic flows. If we make use of SFx extension for cell 
> information then it may be confusing with traffic flows in the future.
>
> What do you think ?
>
> With Regards,
>
> Satish.
>
> *From:*6tisch [mailto:[email-masked]] *On Behalf Of *Prof. 
> Diego Dujovne
> *Sent:* 2016年5月19日21:40
> *To:* Pascal Thubert (pthubert)
> *Cc:* [email-masked]; S.V.R.Anand; 
> [email-masked]
> 2016-05-19 8:48 GMT-04:00 Pascal Thubert (pthubert) 
> *From:*S.V.R.Anand [mailto:[email-masked] 
> <mailto:[email-masked]>]
> *To:* Pascal Thubert (pthubert) <[email-masked] 
> <mailto:[email-masked]>>; Prof. Diego Dujovne 
> <[email-masked] <mailto:[email-masked]>>
> *Cc:* [email-masked] <mailto:[email-masked]>; 
> [email-masked] 
> <mailto:[email-masked]>
>
>
>     But the fact that one of these units is mapped to a particular
>     slot offset / channel offset should not be its business. I see it
>     as a layer violation…
>
>     <mailto:[email-masked]>
>     *Cc:* [email-masked]
>     <mailto:[email-masked]>;
>     -> This section is recommended by the 6top-protocol draft, and
>     AFAIK it defines which cells are offered and which are selected
>     for allocation.
>
>     -> This section is also recommended by the 6top-protocol draft,
>     and it should include any type of pre-configuration and expected
>     initial state on the SF.
>
>     -> From the comment from Pascal on today's webex: "What if a node
>     has a big storage and it can keep all configuration after a
>     crash?" The SF can
>
>     use that info to reconstruct all the configuration and recover
>     instead of issuing a clear command. However, there must be a
>     timeout period for recover;
>         I would expect that this doc is the reference for SF and is
>         the one that requests the creation of the SF registry by IANA
>         (text to be added in the IANA section).
>
>         -Connectivity to the neighbor is lost. A L3 Link down event
>         should free up resources. The question for 6P is how both
>         sides agree at the same time that the link is down.
>
>         Why is this here? Which cell are allocated is not SF0 ‘s
>         business, is it? OTOH, the semantics of the ADD that is
>         mentioned should be somewhere, and I think, in this document.
>

---

From: "S.V.R.Anand" <[email-masked]>
Date: Fri, 20 May 2016 11:21:30 +0530

Hi Pascal,

Thanks! We will explore the idea further keeping the complexity aspect 
in mind.

Anand

On Thursday 19 May 2016 06:18 PM, Pascal Thubert (pthubert) wrote:
> *From:*S.V.R.Anand [mailto:[email-masked]]
> *To:* Pascal Thubert (pthubert) <[email-masked]>; Prof. Diego 
> Dujovne <[email-masked]>