Subject: [6tisch] Slot type in 6P cell list

From: Sedat Gormus <[email-masked]>
Date: Fri, 3 Jun 2016 15:39:37 +0300

Dear All,

We are working towards implementing a distributed scheduling function.
We have been thinking about the structure of 6P cells where the slotOffset
and channelOffset pairs are used for disseminating information locally. We
think, we might need the slot type information as well to make the correct
scheduling  for our objective. For example, if we want to minimize the
delay, we would like to create a request with a cell list from the next hop
node that guarantees minimum delay. Our requested transmit slots should be
earlier than the next hop's transmit slots in the schedule in order to do
that. But, for this we need to know the type of the slots within the
schedule of our next hop neighbor (parent in RPL case).

Any suggestions on this.

Regards,

Sedat

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 3 Jun 2016 21:44:41 +0200

Sedat,
I'm sorry, but I don't fullly understand your question. It's the SF running
on the nodes which selects the slots, so it can implement any policy it
wants. What doyou mean by "type of slot"?
Thomas

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: Xavier Vilajosana <[email-masked]>
Date: Sat, 4 Jun 2016 06:35:13 +0200

Hi Thomas, Sedat,all

I think he refers to link Option, that is whether the slots being allocated
are tx, rx, both, shared? etc...

The current draft is not explicit with that. The content is implicit in the
direction of the negotiation.

In a 6top negotiation (despite 2 o 3 step process) the origin is requesting
TX cells to the destination. That is if A requests 2 cells to B in the
schedule of A this cells will be marked with the linkOption TX. and in B
will be marked with the linkOption RX.

I guess Sedat is opening a more general question of whether we should
enable allocations such as installing bidirectional links in a single
transaction. E.g when A requests 2 cells to B and one is upstream and the
other is downstream.

regards,
Xavi

2016-06-03 21:44 GMT+02:00 Thomas Watteyne <[email-masked]>:

> Sedat,
> I'm sorry, but I don't fullly understand your question. It's the SF
> running on the nodes which selects the slots, so it can implement any
> policy it wants. What doyou mean by "type of slot"?
> Thomas
>
>> We have been thinking about the structure of 6P cells where the
>> slotOffset and channelOffset pairs are used for disseminating information
>> locally. We think, we might need the slot type information as well to make
>> the correct scheduling  for our objective. For example, if we want to
>> minimize the delay, we would like to create a request with a cell list from
>> the next hop node that guarantees minimum delay. Our requested transmit
>> slots should be earlier than the next hop's transmit slots in the schedule
>> in order to do that. But, for this we need to know the type of the slots
>> within the schedule of our next hop neighbor (parent in RPL case).
>>
>> Any suggestions on this.
>>
>> Regards,
>>
>> Sedat
>>
>
>
> --
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

---

From: Sedat Gormus <[email-masked]>
Date: Sat, 4 Jun 2016 11:46:50 +0300

Xavi has explained my question.

The question here is that do we need to explicitly mark slots as tx, rx and
shared or not?

Will it be beneficial to have such an information for other purposes as
Xavi explained?

Regards,

Sedat

On Sat, Jun 4, 2016 at 7:35 AM, Xavier Vilajosana <
[email-masked]> wrote:

> Hi Thomas, Sedat,all
>
> I think he refers to link Option, that is whether the slots being
> allocated are tx, rx, both, shared? etc...
>
> The current draft is not explicit with that. The content is implicit in
> the direction of the negotiation.
>
> In a 6top negotiation (despite 2 o 3 step process) the origin is
> requesting TX cells to the destination. That is if A requests 2 cells to B
> in the schedule of A this cells will be marked with the linkOption TX. and
> in B will be marked with the linkOption RX.
>

---

From: Qin Wang <[email-masked]>
Date: Mon, 6 Jun 2016 20:35:41 +0000 (UTC)

Hi all,
I think Sedat raised a good question. 
The explicit expression of LinkOption may be more flexible and more efficient if we can find application in which a Node knows the need of two-way communication bandwidth at a time. In  another word, the current assumption for implicit expression is that nodeA initializes a transaction with nodeB when nodeA needs more bandwidth to send data to nodeB. The new assumption for explicit expression is the nodeA knows not only the need of more bandwidth to send data to nodeB, but also knows nodeB will needs more bandwidth for response. I'm not sure if the new assumption makes sense.
What do you think?
ThanksQin

    On Saturday, June 4, 2016 4:47 AM, Sedat Gormus <[email-masked]> wrote:

 Xavi has explained my question. 
The question here is that do we need to explicitly mark slots as tx, rx and shared or not?
Will it be beneficial to have such an information for other purposes as Xavi explained? 
Regards,
Sedat

On Sat, Jun 4, 2016 at 7:35 AM, Xavier Vilajosana <[email-masked]> wrote:

Hi Thomas, Sedat,all
I think he refers to link Option, that is whether the slots being allocated are tx, rx, both, shared? etc...
The current draft is not explicit with that. The content is implicit in the direction of the negotiation.
In a 6top negotiation (despite 2 o 3 step process) the origin is requesting TX cells to the destination. That is if A requests 2 cells to B in the schedule of A this cells will be marked with the linkOption TX. and in B will be marked with the linkOption RX.
I guess Sedat is opening a more general question of whether we should enable allocations such as installing bidirectional links in a single transaction. E.g when A requests 2 cells to B and one is upstream and the other is downstream.

regards,
Xavi  

Sedat,I'm sorry, but I don't fullly understand your question. It's the SF running on the nodes which selects the slots, so it can implement any policy it wants. What doyou mean by "type of slot"?Thomas 
On Friday, June 3, 2016, Sedat Gormus <[email-masked]> wrote:

Dear All,
We are working towards implementing a distributed scheduling function.We have been thinking about the structure of 6P cells where the slotOffset and channelOffset pairs are used for disseminating information locally. We think, we might need the slot type information as well to make the correct scheduling  for our objective. For example, if we want to minimize the delay, we would like to create a request with a cell list from the next hop node that guarantees minimum delay. Our requested transmit slots should be earlier than the next hop's transmit slots in the schedule in order to do that. But, for this we need to know the type of the slots within the schedule of our next hop neighbor (parent in RPL case). 
Any suggestions on this.
Regards,
Sedat

-- 
_______________________________________
Thomas Watteyne, PhDResearch Scientist & Innovator, InriaSr Networking Design Eng, Linear TechFounder & co-lead, UC Berkeley OpenWSNCo-chair, IETF 6TiSCH
www.thomaswatteyne.com_______________________________________

---

From: Xavier Vilajosana <[email-masked]>
Date: Tue, 7 Jun 2016 09:41:31 +0200

Hi Qin, all,
my 2 cents.

the type of application that comes to my mind is an app that requires
request-response behaviour. Example CoAP applications without the Observe
functionality. The question is if that applications are so traffic
demanding that we need symmetric bandwidth to be allocated at once. Or
instead the tracks can be installed in both directions independently.

regards,
X

2016-06-06 22:35 GMT+02:00 Qin Wang <[email-masked]>:

> The explicit expression of LinkOption may be more flexible and more
> efficient if we can find application in which a Node knows the need of
> two-way communication bandwidth at a time. In  another word, the current
> assumption for implicit expression is that nodeA initializes a transaction
> with nodeB when nodeA needs more bandwidth to send data to nodeB. The new
> assumption for explicit expression is the nodeA knows not only the need
> of more bandwidth to send data to nodeB, but also knows nodeB will needs
> more bandwidth for response. I'm not sure if the new assumption makes sense.
>
> What do you think?
>
> Thanks
> Qin
>
>
>
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Jun 2016 08:49:12 +0000

Hello Xavi:

For all I know, SF0 is a blind observant of the bandwidth being used. It is completely separated from the application and the reservation protocol. And 6P is designed to serve that type of user.

Now, say an app, residing in a child 3 hops away from the root, knows it needs one timeslot per unit of time both ways for some new CoAP exchange, and asks an SF to negotiate that with the RPL parent. Certainly there will be a same need along the path to the root?

Tying an SF operation with the application in the node is this a major change of paradigm from SF0, and it yields the question of whether that request should be propagated along the path towards the root, and thus the reservation protocol.

Seems to me your discussion below prepares 6P for that reservation protocol. It would be good to start exploring the consequences on 6P of an SF that is doing dynamically scheduling along a RPL path. Can that be an increment later, or should we cover those needs now?

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: mardi 7 juin 2016 09:42
To: Qin Wang <[email-masked]>
Cc: Sedat Gormus <[email-masked]>; [email-masked]; Thomas Watteyne <[email-masked]>
Subject: Re: [6tisch] Slot type in 6P cell list

Hi Qin, all,
my 2 cents.

the type of application that comes to my mind is an app that requires request-response behaviour. Example CoAP applications without the Observe functionality. The question is if that applications are so traffic demanding that we need symmetric bandwidth to be allocated at once. Or instead the tracks can be installed in both directions independently.

regards,
X

2016-06-06 22:35 GMT+02:00 Qin Wang <[email-masked]<mailto:[email-masked]>>:
Hi all,

What do you think?

Thanks
Qin

On Saturday, June 4, 2016 4:47 AM, Sedat Gormus <[email-masked]<mailto:[email-masked]>> wrote:

Regards,

Sedat

On Sat, Jun 4, 2016 at 7:35 AM, Xavier Vilajosana <[email-masked]<mailto:[email-masked]>> wrote:
Hi Thomas, Sedat,all

regards,
Xavi

2016-06-03 21:44 GMT+02:00 Thomas Watteyne <[email-masked]<mailto:[email-masked]>>:
Sedat,
I'm sorry, but I don't fullly understand your question. It's the SF running on the nodes which selects the slots, so it can implement any policy it wants. What doyou mean by "type of slot"?
Thomas

On Friday, June 3, 2016, Sedat Gormus <[email-masked]<mailto:[email-masked]>> wrote:
Dear All,

We are working towards implementing a distributed scheduling function.
We have been thinking about the structure of 6P cells where the slotOffset and channelOffset pairs are used for disseminating information locally. We think, we might need the slot type information as well to make the correct scheduling  for our objective. For example, if we want to minimize the delay, we would like to create a request with a cell list from the next hop node that guarantees minimum delay. Our requested transmit slots should be earlier than the next hop's transmit slots in the schedule in order to do that. But, for this we need to know the type of the slots within the schedule of our next hop neighbor (parent in RPL case).

Any suggestions on this.

Regards,

Sedat

Thomas Watteyne, PhD

www.thomaswatteyne.com<http://www.thomaswatteyne.com/>
_______________________________________

_______________________________________________
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: "Lijo Thomas" <[email-masked]>
Date: Tue, 7 Jun 2016 15:36:04 +0530

Hi all,
 
I do agree with Pascal.
 
I feel that bidirectional requirement of bandwidth should be handled by PCE (hard cell) only. 
 
Let the Scheduling function SF0 not be tied up with the application

Thanks & Regards,
Lijo Thomas 

From: 6tisch [mailto:[email-masked]] On Behalf Of Pascal Thubert (pthubert)
Sent: 07 June 2016 14:19
To: Xavier Vilajosana; Qin Wang
Cc: Sedat Gormus; [email-masked]; Thomas Watteyne
Subject: Re: [6tisch] Slot type in 6P cell list
 
Hello Xavi:

 

Pascal
 
From: 6tisch [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Xavier Vilajosana
Sent: mardi 7 juin 2016 09:42
To: Qin Wang < <mailto:[email-masked]> [email-masked]>
Cc: Sedat Gormus < <mailto:[email-masked]> [email-masked]>;  <mailto:[email-masked]> [email-masked]; Thomas Watteyne < <mailto:[email-masked]> [email-masked]>
Subject: Re: [6tisch] Slot type in 6P cell list
 
Hi Qin, all,
my 2 cents.

regards,
X 

2016-06-06 22:35 GMT+02:00 Qin Wang < <mailto:[email-masked]> [email-masked]>:
Hi all,

 
What do you think?
 
Thanks
Qin

On Saturday, June 4, 2016 4:47 AM, Sedat Gormus < <mailto:[email-masked]> [email-masked]> wrote:

 
 
Regards,
 
Sedat

On Sat, Jun 4, 2016 at 7:35 AM, Xavier Vilajosana < <mailto:[email-masked]> [email-masked]> wrote:
Hi Thomas, Sedat,all

 

regards,
Xavi

2016-06-03 21:44 GMT+02:00 Thomas Watteyne < <mailto:[email-masked]> [email-masked]>:
Sedat,
I'm sorry, but I don't fullly understand your question. It's the SF running on the nodes which selects the slots, so it can implement any policy it wants. What doyou mean by "type of slot"?
Thomas 

On Friday, June 3, 2016, Sedat Gormus < <mailto:[email-masked]> [email-masked]> wrote:
Dear All,

Any suggestions on this.
 
Regards,
 
Sedat

Thomas Watteyne, PhD
 
 <http://www.thomaswatteyne.com/> www.thomaswatteyne.com
_______________________________________
 
_______________________________________________
6tisch mailing list
 <mailto:[email-masked]> [email-masked]
 <https://www.ietf.org/mailman/listinfo/6tisch> https://www.ietf.org/mailman/listinfo/6tisch

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

-------------------------------------------------------------------------------------------------------------------------------
[ C-DAC is on Social-Media too. Kindly follow us at:
Facebook: https://www.facebook.com/CDACINDIA & Twitter: @cdacindia ]

This e-mail is for the sole use of the intended recipient(s) and may
contain confidential and privileged information. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy
all copies and the original message. Any unauthorized review, use,
disclosure, dissemination, forwarding, printing or copying of this email
is strictly prohibited and appropriate legal action will be taken.
-------------------------------------------------------------------------------------------------------------------------------