Subject: Re: [6tisch] OTF <--> 6top

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 1 Nov 2013 13:09:54 +0000

Coming back to Alfredo's, Maria Rita's and Nicola's point (sorry to jump back in time), I totally agree that it would be good to have a mechanism for a node to reserve a hard cell to its neighbor. But is that mechanism something 6top-to-6top communication should offer, or is it specific to OTF? I would vote for the former.

Thoughts?

+1
The hard cell reservation is not at all OTF-specific. Maybe OTF will need only soft cells (according to the last trend on the ML - anyway this is still something to discuss). But other scheduling mechanisms (different from OTF) may need hard cells, and thus, 6top should offer this functionality. Actually 6top already offers the commands and messages for creating and deleting hard cells. We will need to define mechanisms/ modules for picking specific hard cells,  because this is out of 6top scope. Right?
Maria Rita

On Thu, Oct 31, 2013 at 6:46 AM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Pascal, yes but to see the MAC address you need to receive all the packet -- unless the hardware has special register matching functionalities such some new radios, but this is a specific case, in general we cannot think that this will happen I guess.
:-(
X

On Thu, Oct 31, 2013 at 2:54 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Xavi:

I'd expect that once the MAC address is seen and does not match, the device can go back to sleep?

Pascal

From: Qin Wang [mailto:[email-masked]<mailto:[email-masked]>]
Sent: mercredi 30 octobre 2013 20:49
To: Xavier Vilajosana Guillen
Cc: Pascal Thubert (pthubert); Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]<mailto:[email-masked]>

Subject: Re: [6tisch] OTF <--> 6top

Xavi,

I agree with your concern on energy consumption.

Thanks
Qin

On Thu, Oct 31, 2013 at 3:31 AM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hi Qin, I understand the same,
If we think on A-B and C-D, B and D will be listening at each slotframe on that cell. If there is low traffic they will be idle listening most of the time. When A sends a packet B and D receive it (but D was supposed to be idle listening) so energy is wasted.
that's a point that we need to understand as the gain on using a mux is that we safe cells on the schedule, but nodes sharing cell have the radio more time on as receive packets that are not for them.
X

On Wed, Oct 30, 2013 at 12:25 PM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Xavi,

I'm a little bit confused.  I think VBR means A-B or C-D occupies a entire slot, instead of each of them occupies a part of slot. In another word, if any of them wants to talk, it must start talking at the beginning of a slot, instead of waiting for another pair to complete talk. Maybe my understanding is wrong.

Thanks
Qin

On Thu, Oct 31, 2013 at 3:08 AM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
As regards to Pascal comment:

"In this discussion I'm talking about 6top in node A grabbing a new time slot from some pool for A to B or B to A communication. The question is does A want exclusive control on that slot meaning that it knows it will use it well or could the slot also be used by C to talk to D knowing that either A or C do not talk much so it should mostly be collisionless?"
If A uses the cell to communicate with C and C uses that cell to communicate with D we benefit from the fact that one less cell is used in the schedule, however when A sends the packet, C and D will be listening and they will receive the entire packet meaning that the radio will be on for the duration of an entire packet (in the worst case 127 bytes==4.6ms), if the packet is only for C, D would have wasted some energy (almost double than idle listening).

If C and D have dedicated cells the energy wasting might be less as when C does not send, D only idle listens (during 2*GT -- aprox 2.6ms)
So this has some compromises that we should understand .
X

On Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Hello Qin,

VBR should lead to shared slot to benefit from statistical mux.

Today we have 2 sorts of shared slots:
- slots that are in a bundle A to B are shared between all flows tjat go through A and for which B is next hop. This is a virtual link and changing the size of the bundle changes the speed of that link. This is effectively benefiting from statistical mux.
- p2mp or mp2p slots that a parent allocates to talk to its children or the other  way around.

In this discussion I'm talking about 6top in node A grabbing a new time slot from some pool for A to B or B to A communication. The question is does A want exclusive control on that slot meaning that it knows it will use it well or could the slot also be used by C to talk to D knowing that either A or C do not talk much so it should mostly be collisionless?

This is what I'm talking about here: reservation for VBR...

Pascal

Le 30 oct. 2013 à 19:05, "Qin Wang" <[email-masked]<mailto:[email-masked]>> a écrit :
Hi Pascal,

I agree that cleanup a bundle is an important service from 6top, especially, when node A and node B can not talk with each other anymore. Can we use time-out mechanism to cleanup the bundle by node A and node B independently?

Regarding to VBR vs CBR, my understanding is that CBR cell is the dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR cell different from the Shared cell in TSCH?

Thanks
Qin

On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Dear all:

The decision of increasing the size of a bundle with a neighbor is just one aspect. We also need to decrease the size of the bundle and eventually and clean up. Cleanup may be a hard one if A and B cannot talk anymore at that time.

Then there is the question of the type of slot. It's not just hard vs. soft, but also reserved (eg only A to B with well-known traffic == CBR) vs. statistical multiplexing (A to B but also C to D and E to F, each with stochastic traffic patterns == VBR)

Then there is the question of the picking the slot in the matrix and the strategy to enforce the expected type. I suspect that the granularity of a time slot 1 or 2 hops away yields large inefficiencies... we can probably manipulate chunks of time slots and if we have a PCE, delegate chunks to time slot allocators (eg parents).

I agree with Thomas that the cell selection (within eventually a delegated or autoconf'ed chunk) belongs to 6Top. That is part of the service. From that standpoint the user in abstract. A user can be a local OTF that looks at bandwidth consumption statistics, queue size, discards etc... An it can be a PCE, RSVP...

>From the user perspective (that's a separate discussion) we need to define:
- the policies for allocating and a deallocating resources
- the type of services that are needed (hard vs. soft, VBR vs. CBR ...)

>From the 6top perspective, we need to find:
- the proper APIs to serve the user needs aboce
- where 6top gets the pool(s) of slots it can allocate from (autoconf, delegation ...)
- how 6top negotiate (with next hop 6top) that this service request will be mapped onto this timeslot

I had some slides at the last call but little time. Maybe next Friday, or in Vancouver...

Cheers,

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Qin Wang
Sent: mercredi 30 octobre 2013 15:33
To: Xavier Vilajosana Guillen
Cc: Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] OTF <--> 6top

Hi Maria Rita and all,

Besides re-sizing the bundle, if OTF wants to pick-up hard cells directly, what kinds of statistics from 6top it will need?

Thanks
Qin

On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <[email-masked]<mailto:[email-masked]>> wrote:
Hi,
my opinion is that OTF should use SOFT cells. Using  HARD cells will require a knowledge of the schedules of others (2 hop neighbors at least + hidden terminals) in order to select an appropriate cell. Having a knowledge requires communication and memory which we want to minimize. Using Soft Cells is a 2 message problem, 6top requesting and the neighbor confirming, if collisions 6top takes care of that, OTF does not even realize of the proble. This approach does not require to keep any other state. OTF module can determine how many cells and 6top provide them which makes IMHO the approach very simple.
my thought .. :-)
Xavi

On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
>>>All,

>>>Let's continue this very interesting discussion. Allow me to take a step back.

>>>The original intent for soft cells was that it is hard to ensure entirely collision-free scheduling, especially in a distributed case. Xavi did some simulations early-on, came to the conclusion that the collision probability (i.e. >>>two independent pairs of neighbors choosing the same cell in the schedule) is low in most scenarios. So we introduced the notion of soft cells: you tell 6top how many cells you want to that neighbor, and 6top will install them >>>for you, possibly moving them around in the (low likelyhood) case that there is a collision.

>>>My original thought about OTF was: 6top offers soft cell functionality, let's have a small module above 6top which adjusts the size of the bundles "on-the-fly" as it monitors e.g. queue usage. In that sense, I had imagined OTF >>>to deal strictly with soft cells. OTF can react fast or slow, with advantages in both cases, and hence the more flexible, the better.

>>>With this in mind, I have a hard time understand the use case for reserving hard cells with OTF. Help :)

[MR] Thomas, I also had initially in mind that OTF should deal with SOFT cells. But after I realized that by interacting with 6top, OTF could collect info about the schedule itself, and thus, it could be able to allocate specific HARD cells. This could be useful when OTF needs to react fast. IMHO, the selection of soft cells by 6top may be a slower process. But I may be wrong, and I am completely open to still discuss this point.

>>>Finally, I agree that we are discussing two things:
>>>1. how many cells to have in a bundle
>>>2. which cells to pick in the matrix

[MR] +1

(1)    The bundle size should depend on the queue length (in/out), and thus the amount of traffic to delivery

(2)    Which cells to pick -> by 6top if they are soft cells; by a specific algorithm, running on an external entity (OTF? PCE) if they are hard cell
>>>Maybe we should force ourselves to keep them separated, i.e. have (1) in OTF, and (2) in 6top. This is mainly because RSVP-like reservation (which I imagine running on top of 6top) will need (2), but not (1).

[MR] I agree in keeping them separated, but I would not say that (2) is ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I said above, could be handled by an entity different from 6top.

>>>Thomas

Maria Rita

--------------------------------------------------------------------------------------------------------------------------
On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <[email-masked]<mailto:[email-masked]>> wrote:
Dear all:

Please keep in mind that the traffic is not all collection tree. A common parent will route downwards traffic that it got from under.
I hope we have time at the call to discuss this more.

Cheers,

Pascal

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Maria Rita PALATTELLA
Sent: jeudi 24 octobre 2013 23:26
To: [email-masked]<mailto:[email-masked]>
Cc: Prof. Diego Dujovne ([email-masked]<mailto:[email-masked]>)
Subject: [6tisch] OTF <--> 6top

Dear all,
Let's keep in discussing about the on-the-fly scheduling, and its interaction with 6top.
Here are two possible algorithms that OTF could use (summarized by Diego). But there are still some issue/open points to be discussed.
I left some comments. Your feedback are welcome.
Best regards,
Maria Rita

Algorithm A (Pascal's contribution)

- Queue behavior as a input parameters. Whenever a predefined threshold is reached, the bundle size increases:

- Queue size at Enqueue (more traffic waiting)

- Latency at Dequeue (very slow transmission)

 Here, bundle size depends on queue size values. Individual cells within the bundle should be

managed inside OTF for very fast response.

[MR] It is not so clear to me what you mean with << Individual cells within the bundle should be managed inside OTF for very fast response >>

Having in mind that OTF should be a module interacting with 6top sublayer and using its functionalities, my understanding of the above sentence is as follow: OTF should select the cells within the schedule, and ask 6top to allocate these HARD cells. Is it correct?

Algorithm B (Prof. Pister's contribution)

- Knowledge of node self-requirements: The node knows:

- its own desired bandwidth (in cells/s) to the destination

Desired bandwidth can change on application performance (e.g. round-trip latency) or MAC performance (measured PDR, queue length)

- incoming bandwidth from children (cells/s)

- outgoing bandwidth to parents (cells/s)

As a result, a proposed algorithm would be:

- if (outgoing<incoming+self) pick best parent and add new cell

- if (outgoing>incoming+self+1) pick the worst cell and delete it
This requires individual cell mangement, but something like a hybrid approach (bundle size change for slow trends, individual cell management
within OTF for fast response could be a nice solution)
[MR] same comment as above
One of the discussions here is how to choose the worst cell
 [MR] I guess we will not only need to define a criteria for selecting the worst cell, but also decide if the knowledge of "worst cell" is shared by all the neighbor nodes, or each of them can select as worst cell a different one...
Why don't we allow 6top to compute the worst cell while collecting the statistics? I think it will be easier for OTF getting the info from 6top, instead of computing the worst cell on its own... what do you think?
Maybe we can define the metrics that 6top can use for computing the worst cell. And based on the application, the node will give to 6top the parameters to use as input for the computation of the worst cell.

Also, since there are per-neighbour statistics, we must agree on the
algorithm to decide on which neighbour (from the neighbour table) execute
the algorithm. I proposed to be the one which has at least one packet
pending on the queue. This would save energy and processing resources.
 [MR] or the neighbor that has the longer queue.

_______________________________________________
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

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

---

From: Qin Wang <[email-masked]>
Date: Fri, 1 Nov 2013 22:20:24 +0800

Hi Maria Rita,

As we discussed before, 6top provides the services to operate hard cells
and soft cells, and theoretically all of the services can be used in
centralized or distributed way. But, I would like to vote that OTF focuses
on playing soft cells for two reasons: (1) it is really a missing piece;
(2) I think we need to do more research to understand how to play hard
cells locally and what the cost and benefit is. But if we find something
missing in 6top to support future extension, I believe we should consider
right now.

What do you think?
Qin

On Fri, Nov 1, 2013 at 9:09 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

>   Coming back to *Alfredo*'s, *Maria Rita*'s and * Nicola*'s point (sorry
> to jump back in time), I totally agree that it would be good to have a
> mechanism for a node to reserve a hard cell to its neighbor. But is that
> mechanism something 6top-to-6top communication should offer, or is it
> specific to OTF? I would vote for the former.****
>
> ** **
>
> Thoughts?****
>
> ** **
>
> *+1*
>
> *The hard cell reservation is not at all OTF-specific. Maybe OTF will
> need only soft cells (according to the last trend on the ML – anyway this
> is still something to discuss). But other scheduling mechanisms (different
> from OTF) may need hard cells, and thus, 6top should offer this
> functionality. Actually 6top already offers the commands and messages for
> creating and deleting hard cells. We will need to define mechanisms/
> modules for picking specific hard cells,  because this is out of 6top
> scope. Right?*
>
> *Maria Rita*
>
> * *
>
> On Thu, Oct 31, 2013 at 6:46 AM, Xavier Vilajosana Guillen <
> [email-masked]> wrote:****
>
> Hi Pascal, yes but to see the MAC address you need to receive all the
> packet -- unless the hardware has special register matching functionalities
> such some new radios, but this is a specific case, in general we cannot
> think that this will happen I guess.****
>
> :-(****
>
> X****
>
> ** **
>
> On Thu, Oct 31, 2013 at 2:54 AM, Pascal Thubert (pthubert) <
> [email-masked]> wrote:****
>
> Hello Xavi:****
>
>  ****
>
> I’d expect that once the MAC address is seen and does not match, the
> device can go back to sleep?****
>
>  ****
>
> Pascal****
>
>  ****
>
> *From:* Qin Wang [mailto:[email-masked]]
> *Sent:* mercredi 30 octobre 2013 20:49
> *To:* Xavier Vilajosana Guillen
> *Cc:* Pascal Thubert (pthubert); Maria Rita PALATTELLA; Thomas Watteyne;
> [email-masked]****
>
>
> *Subject:* Re: [6tisch] OTF <--> 6top****
>
>  ****
>
> Xavi,****
>
>  ****
>
> I agree with your concern on energy consumption.****
>
>  ****
>
> Thanks****
>
> Qin ****
>
>  ****
>
> On Thu, Oct 31, 2013 at 3:31 AM, Xavier Vilajosana Guillen <
> [email-masked]> wrote:****
>
> Hi Qin, I understand the same,****
>
> If we think on A-B and C-D, B and D will be listening at each slotframe on
> that cell. If there is low traffic they will be idle listening most of the
> time. When A sends a packet B and D receive it (but D was supposed to be
> idle listening) so energy is wasted.****
>
> that's a point that we need to understand as the gain on using a mux is
> that we safe cells on the schedule, but nodes sharing cell have the radio
> more time on as receive packets that are not for them.****
>
> X****
>
>  ****
>
> On Wed, Oct 30, 2013 at 12:25 PM, Qin Wang <[email-masked]> wrote:**
> **
>
> Xavi,****
>
>  ****
>
> I'm a little bit confused.  I think VBR means A-B or C-D occupies a entire
> slot, instead of each of them occupies a part of slot. In another word, if
> any of them wants to talk, it must start talking at the beginning of a
> slot, instead of waiting for another pair to complete talk. Maybe my
> understanding is wrong.****
>
>  ****
>
> Thanks****
>
> Qin****
>
>  ****
>
> On Thu, Oct 31, 2013 at 3:08 AM, Xavier Vilajosana Guillen <
> [email-masked]> wrote:****
>
> As regards to Pascal comment:****
>
>
>
> "In this discussion I'm talking about 6top in node A grabbing a new time
> slot from some pool for A to B or B to A communication. The question is
> does A want exclusive control on that slot meaning that it knows it will
> use it well or could the slot also be used by C to talk to D knowing that
> either A or C do not talk much so it should mostly be collisionless?"****
>
> If A uses the cell to communicate with C and C uses that cell to
> communicate with D we benefit from the fact that one less cell is used in
> the schedule, however when A sends the packet, C and D will be listening
> and they will receive the entire packet meaning that the radio will be on
> for the duration of an entire packet (in the worst case 127 bytes==4.6ms),
> if the packet is only for C, D would have wasted some energy (almost double
> than idle listening).
>
> If C and D have dedicated cells the energy wasting might be less as when C
> does not send, D only idle listens (during 2*GT -- aprox 2.6ms)****
>
> X ****
>  ****
>  ****
> On Wed, Oct 30, 2013 at 11:26 AM, Pascal Thubert (pthubert) <
> [email-masked]> wrote:****
>
> Hello Qin,****
>
>  ****
>
> VBR should lead to shared slot to benefit from statistical mux.****
>
>  ****
>
> Today we have 2 sorts of shared slots:****
>
> - slots that are in a bundle A to B are shared between all flows tjat go
> through A and for which B is next hop. This is a virtual link and changing
> the size of the bundle changes the speed of that link. This is effectively
> benefiting from statistical mux. ****
>
> - p2mp or mp2p slots that a parent allocates to talk to its children or
> the other  way around.****
>
>  ****
>
> In this discussion I'm talking about 6top in node A grabbing a new time
> slot from some pool for A to B or B to A communication. The question is
> does A want exclusive control on that slot meaning that it knows it will
> use it well or could the slot also be used by C to talk to D knowing that
> either A or C do not talk much so it should mostly be collisionless?
>
> Pascal****
> Le 30 oct. 2013 à 19:05, "Qin Wang" <[email-masked]> a écrit :****
>
>  Hi Pascal, ****
>
>  ****
>
> I agree that cleanup a bundle is an important service from 6top,
> especially, when node A and node B can not talk with each other anymore.
> Can we use time-out mechanism to cleanup the bundle by node A and node B
> independently?****
>
>  ****
>
> Regarding to VBR vs CBR, my understanding is that CBR cell is the
> dedicated cell, i.e. Tx or Rx cell in TSCH. But what is VBR cell? Is VBR
> cell different from the Shared cell in TSCH?****
>
>  ****
>
> Thanks****
>
> Qin****
>
>  ****
>
>  ****
>
> On Thu, Oct 31, 2013 at 12:21 AM, Pascal Thubert (pthubert) <
> [email-masked]> wrote:****
>
> Dear all:****
>
>  ****
>
> The decision of increasing the size of a bundle with a neighbor is just
> one aspect. We also need to decrease the size of the bundle and eventually
> and clean up. Cleanup may be a hard one if A and B cannot talk anymore at
> that time.****
>
>  ****
>
> Then there is the question of the type of slot. It’s not just hard vs.
> soft, but also reserved (eg only A to B with well-known traffic == CBR) vs.
> statistical multiplexing (A to B but also C to D and E to F, each with
> stochastic traffic patterns == VBR)****
>
>  ****
>
> Then there is the question of the picking the slot in the matrix and the
> strategy to enforce the expected type. I suspect that the granularity of a
> time slot 1 or 2 hops away yields large inefficiencies… we can probably
> manipulate chunks of time slots and if we have a PCE, delegate chunks to
> time slot allocators (eg parents).****
>
>  ****
>
> I agree with Thomas that the cell selection (within eventually a delegated
> or autoconf’ed chunk) belongs to 6Top. That is part of the service. From
> that standpoint the user in abstract. A user can be a local OTF that looks
> at bandwidth consumption statistics, queue size, discards etc… An it can be
> a PCE, RSVP...  ****
>
>  ****
>
>  ****
>
> From the user perspective (that’s a separate discussion) we need to define:
> ****
>
> - the policies for allocating and a deallocating resources****
>
> - the type of services that are needed (hard vs. soft, VBR vs. CBR …) ****
>
>  ****
>
> From the 6top perspective, we need to find:****
>
> - the proper APIs to serve the user needs aboce****
>
> - where 6top gets the pool(s) of slots it can allocate from (autoconf,
> delegation …) ****
>
> - how 6top negotiate (with next hop 6top) that this service request will
> be mapped onto this timeslot****
>
>  ****
>
> I had some slides at the last call but little time. Maybe next Friday, or
> in Vancouver…****
>
>  ****
>
> Cheers,****
>
>  ****
>
> Pascal****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Qin Wang
> *Sent:* mercredi 30 octobre 2013 15:33
> *To:* Xavier Vilajosana Guillen
> *Cc:* Maria Rita PALATTELLA; Thomas Watteyne; [email-masked]
> *Subject:* Re: [6tisch] OTF <--> 6top****
>
>  ****
>
> Hi Maria Rita and all,****
>
>  ****
>
> Besides re-sizing the bundle, if OTF wants to pick-up hard cells directly,
> what kinds of statistics from 6top it will need?****
>
>  ****
>
> Thanks****
>
> Qin****
>
>  ****
>
> On Wed, Oct 30, 2013 at 9:59 PM, Xavier Vilajosana Guillen <
> [email-masked]> wrote:****
>
> Hi,****
>
> my opinion is that OTF should use SOFT cells. Using  HARD cells will
> require a knowledge of the schedules of others (2 hop neighbors at least +
> hidden terminals) in order to select an appropriate cell. Having a
> knowledge requires communication and memory which we want to minimize.
> Using Soft Cells is a 2 message problem, 6top requesting and the neighbor
> confirming, if collisions 6top takes care of that, OTF does not even
> realize of the proble. This approach does not require to keep any other
> state. OTF module can determine how many cells and 6top provide them which
> makes IMHO the approach very simple.****
>
> my thought .. :-)
> Xavi****
>
>  ****
>
> On Wed, Oct 30, 2013 at 1:29 AM, Maria Rita PALATTELLA <
> [email-masked]> wrote:****
>
> >>>All,****
>
>  ****
>
> >>>Let's continue this very interesting discussion. Allow me to take a
> step back.****
>
>  ****
>
> >>>The original intent for soft cells was that it is hard to ensure
> entirely collision-free scheduling, especially in a distributed case. Xavi
> did some simulations early-on, came to the conclusion that the collision
> probability (i.e. >>>two independent pairs of neighbors choosing the same
> cell in the schedule) is low in most scenarios. So we introduced the notion
> of soft cells: you tell 6top how many cells you want to that neighbor, and
> 6top will install them >>>for you, possibly moving them around in the (low
> likelyhood) case that there is a collision.****
>
>  ****
>
> >>>My original thought about OTF was: 6top offers soft cell functionality,
> let's have a small module above 6top which adjusts the size of the bundles
> "on-the-fly" as it monitors e.g. queue usage. In that sense, I had imagined
> OTF >>>to deal strictly with soft cells. OTF can react fast or slow, with
> advantages in both cases, and hence the more flexible, the better.****
>
>  ****
>
> >>>With this in mind, I have a hard time understand the use case for
> reserving hard cells with OTF. Help :)****
>
>  ****
>
> [MR] Thomas, I also had initially in mind that OTF should deal with SOFT
> cells. But after I realized that by interacting with 6top, OTF could
> collect info about the schedule itself, and thus, it could be able to
> allocate specific HARD cells. This could be useful when OTF needs to react
> fast. IMHO, the selection of soft cells by 6top may be a slower process.
> But I may be wrong, and I am completely open to still discuss this point.*
> ***
>
>  ****
>
> >>>Finally, I agree that we are discussing two things:****
>
> >>>1. how many cells to have in a bundle****
>
> >>>2. which cells to pick in the matrix****
>
>  ****
>
> [MR] +1 ****
>
> (1)    The bundle size should depend on the queue length (in/out), and
> thus the amount of traffic to delivery****
>
> (2)    Which cells to pick -> by 6top if they are soft cells; by a
> specific algorithm, running on an external entity (OTF? PCE) if they are
> hard cell****
>
> >>>Maybe we should force ourselves to keep them separated, i.e. have (1)
> in OTF, and (2) in 6top. This is mainly because RSVP-like reservation
> (which I imagine running on top of 6top) will need (2), but not (1).****
>
>  ****
>
> [MR] I agree in keeping them separated, but I would not say that (2) is
> ALWAYS in 6top. It is if we consider only SOFT cells, otherwise (2), as I
> said above, could be handled by an entity different from 6top.****
>
>  ****
>
> >>>Thomas****
>
>  ****
>
> Maria Rita****
>
>  ****
>
>
> ****
> On Fri, Oct 25, 2013 at 8:02 AM, Pascal Thubert (pthubert) <
> [email-masked]> wrote:****
>
> Dear all:****
>
>  ****
>
> Please keep in mind that the traffic is not all collection tree. A common
> parent will route downwards traffic that it got from under.****
>
> I hope we have time at the call to discuss this more.****
>
>  ****
>
> Cheers,****
>
>  ****
>
> Pascal****
>
>  ****
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Maria Rita PALATTELLA
> *Sent:* jeudi 24 octobre 2013 23:26
> *To:* [email-masked]
> *Cc:* Prof. Diego Dujovne ([email-masked])
> *Subject:* [6tisch] OTF <--> 6top****
>
>  ****
>
> Dear all,****
>
> Let’s keep in discussing about the on-the-fly scheduling, and its
> interaction with 6top.****
>
> Here are two possible algorithms that OTF could use (summarized by Diego).
> But there are still some issue/open points to be discussed.****
>
> I left some comments. Your feedback are welcome.****
>
> Best regards,****
>
> Maria Rita****
>
>  ****
>
> Algorithm A (Pascal's contribution)****
>
> - Queue behavior as a input parameters. Whenever a predefined threshold is
> reached, the bundle size increases:****
>
> - Queue size at Enqueue (more traffic waiting)****
>
> - Latency at Dequeue (very slow transmission)****
>
>  Here, bundle size depends on queue size values. Individual cells within
> the bundle should be****
>
> managed inside OTF for very fast response.****
>
> *[MR] It is not so clear to me what you mean with <<** Individual cells
> within the bundle should be managed inside OTF for very fast response >>**
> ***
>
> *Having in mind that OTF should be a module interacting with 6top
> sublayer and using its functionalities, my understanding of the above
> sentence is as follow: OTF should select the cells within the schedule, and
> ask 6top to allocate these HARD cells. Is it correct?*****
>
>
> Algorithm B (Prof. Pister's contribution) ****
>
> - Knowledge of node self-requirements: The node knows:****
>
> - its own desired bandwidth (in cells/s) to the destination****
>
> Desired bandwidth can change on application performance (e.g. round-trip
> latency) or MAC performance (measured PDR, queue length) ****
>
> - incoming bandwidth from children (cells/s)****
>
> - outgoing bandwidth to parents (cells/s)****
>
> As a result, a proposed algorithm would be:****
>
> - if (outgoing<incoming+self) pick best parent and add new cell****
>
> - if (outgoing>incoming+self+1) pick the worst cell and delete it ****
>
> This requires individual cell mangement, but something like a hybrid
> approach (bundle size change for slow trends, *individual cell management*
> ****
>
> *within OTF for fast response could be a nice solution*)****
>
> *[MR] same comment as above*****
>
> One of the discussions here is how to choose the *worst cell*****
>
> * [MR] I guess we will not only need to define a criteria for selecting
> the worst cell, but also decide if the knowledge of “worst cell” is shared
> by all the neighbor nodes, or each of them can select as worst cell a
> different one…*****
>
> *Why don’t we allow 6top to compute the worst cell while collecting the
> statistics? I think it will be easier for OTF getting the info from 6top,
> instead of computing the worst cell on its own… what do you think?*****
>
> *Maybe we can define the metrics that 6top can use for computing the
> worst cell. And based on the application, the node will give to 6top the
> parameters to use as input for the computation of the worst cell.*****
>
>  ****
>
> pending on the queue. This would save energy and processing resources.****
>
>  *[MR] or the neighbor that has the longer queue.*****
>
>  ****
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch****
>
>  ****
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch****
>
>  ****
>
>
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch****
>
>  ****
>
>  ****
>
>    ****
>
>  ****
>
>  ****
>
>  ****
>
> ** **
>
> ** **
>
> [email-masked]

---

From: Alfredo Grieco <[email-masked]>
Date: Fri, 1 Nov 2013 17:05:26 +0100

Hi Thomas, and all,

>From my point of view, whatever the kind of cell is, OTF will simply ask
6top to install cells. It will never reference a specific cell but it will
simply inform 6top about the amount of bandwidth that is required.

A natural usage of OTF is related to the management of soft cell requests:
we all agree on that ?

The controversial point (from what i understood) is related to the question
whether OTF should be allowed to ask 6top for hard cells too or not. Xavi
and Qin say that this kind of local reinforcement mechanism requires new
research and could inflate the overhead. I agree, but designing now OTF in
order to enable both kinds requests (hard and soft) does not automatically
imply that 6top has to be able to handle both. What I propose is to keep
OTF general enough. 6top will do what it can be done with the state of the
art solutions. It is not said that in the short future we will be not able
to handle local assignments of hard cell. In that case, we will just need
to add new features to 6top only withut touching OTF.

what do you think ?

Cheers

Al

Il giorno venerdì 1 novembre 2013, Thomas Watteyne ha scritto:

> On this last point, I would agree that the destination MAC address is sent
> early on in the packet (even before the source MAC address in the 15.4
> header, is was designed exactly with destination filtering in mind), so D
> might be able to stop listening after only receiving ~10 bytes. As Xavi
> points out, this requires some mechanism to filter close to the PHY layer,
> but radios have been able to do that for a while now.
>
> Coming back to *Alfredo*'s, *Maria Rita*'s and *Nicola*'s point (sorry to
> jump back in time), I totally agree that it would be good to have a
> specific to OTF? I would vote for the former.
>
> Thoughts?
>
>
> [email-masked]> wrote:
>
> think that this will happen I guess.
>
> :-(
> X
>
>
> [email-masked]> wrote:
>
>  Hello Xavi:****
>
> ** **
>

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 1 Nov 2013 17:43:53 -0700

Alfredo, Qin,

I believe we are exactly on the same line:

   - 6top is the generic piece, designed to allow to schedule both hard and
   soft cells between neighbors (the former is missing now, but will be added).
   - OTF is a specific "client" of 6top which uses the 6top interface to
   schedule soft cells.
   - Some other future client will use the 6top API to schedule hard cells.

The architecture that we are getting at is one where 6top is the common
denominator. It defines a clear command set, and translations of that
command set into packet formats and "transport" mechanisms (e.g. IEs).

The challenge is that we want this command set to be able to support the
current (OTF) and future ("hard cell OTF") scheduling solutions. What we
need to do now is, for each solution, identify what the packet exchange
between nodes looks like, and make sure that 6top supports that.

I hope this makes sense.

Thomas

On Fri, Nov 1, 2013 at 9:05 AM, Alfredo Grieco <[email-masked]>wrote:

> The controversial point (from what i understood) is related to the
> question whether OTF should be allowed to ask 6top for hard cells too or
> not. Xavi and Qin say that this kind of local reinforcement mechanism
> requires new research and could inflate the overhead. I agree, but
> designing now OTF in order to enable both kinds requests (hard and
> soft) does not automatically imply that 6top has to be able to handle both.
> What I propose is to keep OTF general enough. 6top will do what it can be
> done with the state of the art solutions. It is not said that in the short
> future we will be not able to handle local assignments of hard cell. In
> that case, we will just need to add new features to 6top only withut
> touching OTF.
>
> what do you think ?
>
> Cheers
>
> Al
>
>
>
>
>
>> Coming back to *Alfredo*'s, *Maria Rita*'s and *Nicola*'s point (sorry
>> device can go back to sleep?
>>
>>
>>
>> Pascal
>>
>>
>>
>> *Subject:* Re: [6tisch] OTF <--> 6top
>>
>>
>>
>> Xavi,
>>
>>
>>
>> If we think on A-B and C-D, B and D will be listening at each slotframe
>> on that cell. If there is low traffic they will be idle listening most of
>> the time. When A sends a packet B and D receive it (but D was supposed to
>> be idle listening) so energy is wasted.
>>
>> more time on as receive packets that are not for them.
>>
>> X
>>
>>
>>
>> On Wed, Oct 30, 2013 at 12:25 PM, Qin Wang <[email-masked]> wrote:
>>
>> Xavi,
>>
>>
>>
>>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Mon, 4 Nov 2013 09:58:08 +0000

Hello Qin,
--  sorry for my late reply --
I agree with you that there is still some work/research to do on the hard cell reservation, and maybe there are some missing pieces in 6top, but it is hard now to identify them...
For sure, we will have a clearer picture of what is missing, once we define some mechanisms for hard cell reservation. Do you agree?
Maria Rita

From: Qin Wang [mailto:[email-masked]]
Sent: Friday, November 01, 2013 3:20 PM
To: Maria Rita PALATTELLA
Cc: Thomas Watteyne; [email-masked]
Subject: Re: [6tisch] OTF <--> 6top

Hi Maria Rita,

As we discussed before, 6top provides the services to operate hard cells and soft cells, and theoretically all of the services can be used in centralized or distributed way. But, I would like to vote that OTF focuses on playing soft cells for two reasons: (1) it is really a missing piece; (2) I think we need to do more research to understand how to play hard cells locally and what the cost and benefit is. But if we find something missing in 6top to support future extension, I believe we should consider right now.

What do you think?
Qin

On Fri, Nov 1, 2013 at 9:09 PM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Coming back to Alfredo's, Maria Rita's and Nicola's point (sorry to jump back in time), I totally agree that it would be good to have a mechanism for a node to reserve a hard cell to its neighbor. But is that mechanism something 6top-to-6top communication should offer, or is it specific to OTF? I would vote for the former.

Thoughts?

+1

Pascal

Xavi,

Thanks
Qin

Thanks
Qin

Pascal

Thanks
Qin

Cheers,

Pascal

Hi Maria Rita and all,

Thanks
Qin

[MR] +1

Maria Rita

Cheers,

Pascal

Dear all,

---

From: Qin Wang <[email-masked]>
Date: Mon, 4 Nov 2013 22:29:41 +0800

Hi Maria Rita,

I completely agree with you.

Thanks
Qin

On Mon, Nov 4, 2013 at 5:58 PM, Maria Rita PALATTELLA <
[email-masked]> wrote:

> I agree with you that there is still some work/research to do on the hard
> cell reservation, and maybe there are some missing pieces in 6top, but it
> is hard now to identify them…
>
> For sure, we will have a clearer picture of what is missing, once we
> define some mechanisms for hard cell reservation. Do you agree?
>
> Maria Rita
>
>
>
>
>
> *Sent:* Friday, November 01, 2013 3:20 PM
> *To:* Maria Rita PALATTELLA
> *Cc:* Thomas Watteyne; [email-masked]
>
> *The hard cell reservation is not at all OTF-specific. Maybe OTF will need
> only soft cells (according to the last trend on the ML – anyway this is
> still something to discuss). But other scheduling mechanisms (different
> idle listening) so energy is wasted.
>
> understanding is wrong.
> either A or C do not talk much so it should mostly be collisionless?"
>
> does not send, D only idle listens (during 2*GT -- aprox 2.6ms)
>
> benefiting from statistical mux.
>
> the other  way around.
> Le 30 oct. 2013 à 19:05, "Qin Wang" <[email-masked]> a écrit :
>
>  Hi Pascal,
>
>
>
> independently?
> cell different from the Shared cell in TSCH?
>
>
>
> Thanks
>
> Qin
>
>
>
>
>
> that time.
> stochastic traffic patterns == VBR)
>
>
>
> time slot allocators (eg parents).
>
>
>
> a PCE, RSVP...
> - the type of services that are needed (hard vs. soft, VBR vs. CBR …)
>
>
>
> delegation …)
> be mapped onto this timeslot
>
>
>
> in Vancouver…
> what kinds of statistics from 6top it will need?
>
>
>
> Thanks
>
> Qin
>
>
>
> makes IMHO the approach very simple.
>
> my thought .. :-)
> Xavi
>
>
>
> step back.
> likelyhood) case that there is a collision.
>
>
>
> advantages in both cases, and hence the more flexible, the better.
>
>
>
> reserving hard cells with OTF. Help :)
>
>
>
> But I may be wrong, and I am completely open to still discuss this point.
>
>
>
> thus the amount of traffic to delivery
>
> hard cell
> (which I imagine running on top of 6top) will need (2), but not (1).
>
>
>
> said above, could be handled by an entity different from 6top.
>
>
>
> >>>Thomas
>
>
>
> Maria Rita
>
>
>
>
> parent will route downwards traffic that it got from under.
>
> *Subject:* [6tisch] OTF <--> 6top
>
>
>
> Dear all,
>
> interaction with 6top.
> But there are still some issue/open points to be discussed.
>
> reached, the bundle size increases:
>
> the bundle should be
> within the bundle should be managed inside OTF for very fast response >>*
>
> *Having in mind that OTF should be a module interacting with 6top sublayer
> and using its functionalities, my understanding of the above sentence is as
> follow: OTF should select the cells within the schedule, and ask 6top to
> allocate these HARD cells. Is it correct?*
>
>
> latency) or MAC performance (measured PDR, queue length)
>
> *within OTF for fast response could be a nice solution*)
>
> *[MR] same comment as above*
>
> One of the discussions here is how to choose the *worst cell*
>
> different one…*
> instead of computing the worst cell on its own… what do you think?*
>
> *Maybe we can define the metrics that 6top can use for computing the worst
> cell. And based on the application, the node will give to 6top the
> parameters to use as input for the computation of the worst cell.*
>
>
>
>  *[MR] or the neighbor that has the longer queue.*
>
>
>
>