Subject: [6tisch] tracks & soft cells reservation w/ OTF

From: Maria Rita PALATTELLA <[email-masked]>
Date: Thu, 20 Mar 2014 10:50:11 +0000

Dear Qin, Xavi (all)

OTF aims to dynamically allocate (de-allocate) soft cells based on the bandwidth (BDW) needed between two neighbor nodes.
After estimating the BDW (and thus the number of soft cells to be added/deleted), OTF delegates to 6top the actual (de)allocation operation.

Given that each soft cell assigned to two neighbor nodes belongs to a specific TRACK, I was wondering how OTF should deal with this.
I mean, shall we suppose that all the traffic in the network belongs to the same TRACK, in order to simply OTF operation?
At the same time, I believe it is not realistic to assume there is only one track, and thus, one flow in the network. But if we assume that we have more than one flow/track, then, we should have several  OTF instances, one for each track.

Do you think that OTF should check the BDW between two nodes per TRACK? Because if checking the overall BDW, then OTF cannot know, on which track the new soft cell should be added.

Looking forward to receiving your advices on how to deal with tracks and OTF soft cells reservation ...

Thank you in advance!

Best regards,
Maria Rita

---

From: Qin Wang <[email-masked]>
Date: Thu, 20 Mar 2014 07:36:41 -0700 (PDT)

Hi Maira Rita,

I don't exactly know how OTF figures out the demand of add/delete softcells. In my mind, at least, there are two ways. 

(1) The demand is from network point of view, e.g. nodeA wants to create/extend/reduce certain BW to nodeB multi-hop away, then a TrackID should be given. Along the path, OTF will ask 6top to allocate/de-allcoate softcells on the given TrackID.

(2) The demand is from the evaluation of local traffic. In this case, I would like to propose to use Best-effort trackID, i.e. TrackID=(0,0).

What do you think?

Thanks
Qin

On Thursday, March 20, 2014 6:50 PM, Maria Rita PALATTELLA <[email-masked]> wrote:

Dear Qin, Xavi (all)

 
 
Looking forward to receiving your advices on how to deal with tracks and OTF soft cells reservation … 
 
Thank you in advance!
 
Best regards,
Maria Rita

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

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Thu, 20 Mar 2014 15:25:35 +0000

Hello Qin,
OTF will figure out if more or less BDW is needed by using the information that 6top provides, e.g., the stat. about BDW (allocated soft cells, overprovision cells, QoS, NQoS), traffic load on a link, queue length, avg time spent by a pkt in the queue…
Then, which approach shall we use? It is still not so clear to me…but I have the feeling that we should use the specific trackID, and not the Best-effort one. Am I wrong?
Thanks for helping in clarifying that!
Best regards,
Maria Rita

From: Qin Wang [mailto:[email-masked]]
Sent: Thursday, March 20, 2014 3:37 PM
To: Maria Rita PALATTELLA; Qin Wang ([email-masked]); Xavier Vilajosana ([email-masked])
Cc: [email-masked]
Subject: Re: [6tisch] tracks & soft cells reservation w/ OTF

Hi Maira Rita,

What do you think?

Thanks
Qin

On Thursday, March 20, 2014 6:50 PM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Dear Qin, Xavi (all)

Thank you in advance!

Best regards,
Maria Rita

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

---

From: Qin Wang <[email-masked]>
Date: Thu, 20 Mar 2014 10:35:27 -0700 (PDT)

Hi Maria Rita,

I agree that OTF should be able to play on specific Track.

The statistics data is in 4 data structure of MIB.
(1) In CellList. It is per cell statistics, from it upper layer can get per bundle or per track statistics.
(2) In MonitoringStatusList. It is per neighbor & slotframe statistics, from it upper layer can get per bundle overview of scheduling and its performance.
(3) In NeighborList. It is per neighbor statistics, from it upper layer can understand the connectivity of a pair of nodes.
(4) In QueueList. It is per Queue statistics, from it upper layer can know the traffic load.

OTF can combine those statistics to make decision. Make sense?

But, as we discussed before, we may need to clarify the feature of a Queue, corresponding to a slotframe, or a Track, or something else. According to my understanding, Queue should associate with Priority defined in QoS, instead of slotframe or Track. Let's start another thread to discuss the feature of Queue.

Thanks
Qin

On Thursday, March 20, 2014 11:25 PM, Maria Rita PALATTELLA <[email-masked]> wrote:
 
Hello Qin,

 
From:Qin Wang [mailto:[email-masked]] 
Sent: Thursday, March 20, 2014 3:37 PM
To: Maria Rita PALATTELLA; Qin Wang ([email-masked]); Xavier Vilajosana ([email-masked])
Cc: [email-masked]
Subject: Re: [6tisch] tracks & soft cells reservation w/ OTF
 
Hi Maira Rita,

 
 
What do you think?
 
Thanks
Qin

 

 
 
Thank you in advance!
 
Best regards,
Maria Rita

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 20 Mar 2014 18:11:17 -0700

Maria Rita,

Thinking about whether to have one of more tracks in OTF. IMO, a track is a
way to guarantee a level of QoS for some type of traffic versus another,
for example to provide flow isolation. OTF is by definition "best effort"
in that it only deals with soft cells. What is the benefit of having
multiple trackIDs in OTF?

Thomas

On Thu, Mar 20, 2014 at 10:35 AM, Qin Wang <[email-masked]> wrote:

> (2) In MonitoringStatusList. It is per neighbor & slotframe statistics,
> from it upper layer can get per bundle overview of scheduling and its
> performance.
> (3) In NeighborList. It is per neighbor statistics, from it upper layer
> can understand the connectivity of a pair of nodes.
> But, as we discussed before, we may need to clarify the feature of a
> Queue, corresponding to a slotframe, or a Track, or something else.
> According to my understanding, Queue should associate with Priority defined
> in QoS, instead of slotframe or Track. Let's start another thread to
> discuss the feature of Queue.
>
> Thanks
> Qin
>
>
>
>
>
> OTF will figure out if more or less BDW is needed by using the information
> that 6top provides, e.g., the stat. about BDW (allocated soft cells,
> overprovision cells, QoS, NQoS), traffic load on a link, queue length, avg
> time spent by a pkt in the queue...
> Then, which approach shall we use? It is still not so clear to me...but I
> have the feeling that we should use the specific trackID, and not the
> Best-effort one. Am I wrong?
> *From:* Qin Wang [mailto:[email-masked]]
> *Sent:* Thursday, March 20, 2014 3:37 PM
> *To:* Maria Rita PALATTELLA; Qin Wang ([email-masked]); Xavier
> Vilajosana ([email-masked])
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] tracks & soft cells reservation w/ OTF
>
>  Hi Maira Rita,
>
>  I don't exactly know how OTF figures out the demand of add/delete
> softcells. In my mind, at least, there are two ways.
>
>  (1) The demand is from network point of view, e.g. nodeA wants to
> create/extend/reduce certain BW to nodeB multi-hop away, then a TrackID
> should be given. Along the path, OTF will ask 6top to allocate/de-allcoate
> softcells on the given TrackID.
>
>  (2) The demand is from the evaluation of local traffic. In this case, I
> would like to propose to use Best-effort trackID, i.e. TrackID=(0,0).
>
>  What do you think?
>
>  Thanks
>  Qin
>
>
>
>  OTF aims to dynamically allocate (de-allocate) soft cells based on the
> bandwidth (BDW) needed between two neighbor nodes.
>  After estimating the BDW (and thus the number of soft cells to be
> added/deleted), OTF delegates to 6top the actual (de)allocation operation.
>
>  Given that each soft cell assigned to two neighbor nodes belongs to a
> specific TRACK, I was wondering how OTF should deal with this.
>  I mean, shall we suppose that all the traffic in the network belongs to
> the same TRACK, in order to simply OTF operation?
>  At the same time, I believe it is not realistic to assume there is only
> one track, and thus, one flow in the network. But if we assume that we have
> more than one flow/track, then, we should have several  OTF instances, one
> for each track.
>
>  Do you think that OTF should check the BDW between two nodes per TRACK?
> Because if checking the overall BDW, then OTF cannot know, on which track
> the new soft cell should be added.
>

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 21 Mar 2014 09:13:44 +0000

Hi Qin, thanks for your detailed email.
I am afraid I am still missing something… concerning bundle and track…
When talking about CellList, you make a difference between getting stat. per bundle or per track.
But shouldn’t a bundle be associated to a specific track, given that each cell (and, thus each cell in the bundle) has a TrackID?
Thanks
Maria Rita

From: Qin Wang [mailto:[email-masked]]
Sent: Thursday, March 20, 2014 6:35 PM
To: Maria Rita PALATTELLA; Qin Wang ([email-masked]); Xavier Vilajosana ([email-masked])
Cc: [email-masked]
Subject: Re: [6tisch] tracks & soft cells reservation w/ OTF

Hi Maria Rita,

Thanks
Qin

On Thursday, March 20, 2014 11:25 PM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Hello Qin,
OTF will figure out if more or less BDW is needed by using the information that 6top provides, e.g., the stat. about BDW (allocated soft cells, overprovision cells, QoS, NQoS), traffic load on a link, queue length, avg time spent by a pkt in the queue…
Then, which approach shall we use? It is still not so clear to me…but I have the feeling that we should use the specific trackID, and not the Best-effort one. Am I wrong?
Thanks for helping in clarifying that!
Best regards,
Maria Rita

From: Qin Wang [mailto:[email-masked]]
Sent: Thursday, March 20, 2014 3:37 PM
To: Maria Rita PALATTELLA; Qin Wang ([email-masked]<mailto:[email-masked]>); Xavier Vilajosana ([email-masked]<mailto:[email-masked]>)
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] tracks & soft cells reservation w/ OTF

Hi Maira Rita,

What do you think?

Thanks
Qin

Thank you in advance!

Best regards,
Maria Rita

---

From: Maria Rita PALATTELLA <[email-masked]>
Date: Fri, 21 Mar 2014 09:25:52 +0000

Thomas,
IMHO OTF is not just a best-effort service.... By checking the BDW's needs, and adding/deleting soft cells, it should provide more than a best effort service... I may be wrong, but this is my understanding.
And I am afraid that by applying OTF ONLY to the best effort track, TrackID =(0,0), we do not really exploit the advantages that OTF can offer...
For sure in the network we will have several flows, and thus, different tracks.
Moreover, when collecting the stat. we will do that per bundle, and thus per track (if my understanding of bundle is correct...)
The new cells to add, or the old cells to be deleted will belong to a given bundle and track.
In a network for sure we will have a best-effort traffic but this may be not the main traffic load, and moreover OTF should help in improving the QoS of the other Tracks, having higher priority.
What do you think?
Maria Rita

From: [email-masked] [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: Friday, March 21, 2014 2:11 AM
To: Qin Wang
Cc: Maria Rita PALATTELLA; Qin Wang ([email-masked]); Xavier Vilajosana ([email-masked]); [email-masked]
Subject: Re: [6tisch] tracks & soft cells reservation w/ OTF

Maria Rita,

Thinking about whether to have one of more tracks in OTF. IMO, a track is a way to guarantee a level of QoS for some type of traffic versus another, for example to provide flow isolation. OTF is by definition "best effort" in that it only deals with soft cells. What is the benefit of having multiple trackIDs in OTF?

Thomas

On Thu, Mar 20, 2014 at 10:35 AM, Qin Wang <[email-masked]<mailto:[email-masked]>> wrote:
Hi Maria Rita,

Thanks
Qin

On Thursday, March 20, 2014 11:25 PM, Maria Rita PALATTELLA <[email-masked]<mailto:[email-masked]>> wrote:
Hello Qin,
OTF will figure out if more or less BDW is needed by using the information that 6top provides, e.g., the stat. about BDW (allocated soft cells, overprovision cells, QoS, NQoS), traffic load on a link, queue length, avg time spent by a pkt in the queue...
Then, which approach shall we use? It is still not so clear to me...but I have the feeling that we should use the specific trackID, and not the Best-effort one. Am I wrong?
Thanks for helping in clarifying that!
Best regards,
Maria Rita

From: Qin Wang [mailto:[email-masked]<mailto:[email-masked]>]

Hi Maira Rita,

What do you think?

Thanks
Qin

Thank you in advance!

Best regards,
Maria Rita

---

From: "Prof. Diego Dujovne" <[email-masked]>
Date: Fri, 21 Mar 2014 06:26:00 -0300

Dear all,
             Following Thomas' comments, in OTF, we are mostly dealing with
the amount of reserved BW to each neighbour node. So,  I think we need, in
order to obtain queue statistics, either to use a per-neighbour track or to
create a per-bundle queue.  What do you think?

               Diego
El 21/03/2014 06:13, "Maria Rita PALATTELLA" <[email-masked]>
escribió:

> I am afraid I am still missing something... concerning bundle and track...
>
> But shouldn't a bundle be associated to a specific track, given that each
> cell (and, thus each cell in the bundle) has a TrackID?
>
> Thanks
>
> Maria Rita
>
>
>
> *Sent:* Thursday, March 20, 2014 6:35 PM
> *From:* Qin Wang [mailto:[email-masked] <[email-masked]>]

---

From: Qin Wang <[email-masked]>
Date: Fri, 21 Mar 2014 06:30:34 -0700 (PDT)

Hi Maria Rita,

Regarding to the Bundle and Track, my understanding is: bundle is a set of cells to a specific neighbor, i.e. representing a link of some BW; track is a set of cells to a specific neighbor and must be associated with a specific multi-hop path. In another word, from one-hop point of view, a bundle may correspond to more than one tracks. What do you think?

Thanks
Qin

On Friday, March 21, 2014 5:13 PM, Maria Rita PALATTELLA <[email-masked]> wrote:

 
Hi Maria Rita,

 

Thanks
Qin

 

 
 
Hi Maira Rita,

 
 
What do you think?
 
Thanks
Qin

 

 
 
Thank you in advance!
 
Best regards,
Maria Rita