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 protected]] On Behalf Of Pascal Thubert (pthubert) Sent: 07 June 2016 14:19 To: Xavier Vilajosana; Qin Wang Cc: Sedat Gormus; [email protected]; Thomas Watteyne Subject: Re: [6tisch] Slot type in 6P cell list 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 protected]> mailto:[email protected]] On Behalf Of Xavier Vilajosana Sent: mardi 7 juin 2016 09:42 To: Qin Wang < <mailto:[email protected]> [email protected]> Cc: Sedat Gormus < <mailto:[email protected]> [email protected]>; <mailto:[email protected]> [email protected]; Thomas Watteyne < <mailto:[email protected]> [email protected]> 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 < <mailto:[email protected]> [email protected]>: 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? Thanks Qin On Saturday, June 4, 2016 4:47 AM, Sedat Gormus < <mailto:[email protected]> [email protected]> 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 < <mailto:[email protected]> [email protected]> 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 2016-06-03 21:44 GMT+02:00 Thomas Watteyne < <mailto:[email protected]> [email protected]>: 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 protected]> [email protected]> 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 Research Scientist & Innovator, Inria Sr Networking Design Eng, Linear Tech Founder & co-lead, UC Berkeley OpenWSN Co-chair, IETF 6TiSCH <http://www.thomaswatteyne.com/> www.thomaswatteyne.com _______________________________________ _______________________________________________ 6tisch mailing list <mailto:[email protected]> [email protected] <https://www.ietf.org/mailman/listinfo/6tisch> https://www.ietf.org/mailman/listinfo/6tisch _______________________________________________ 6tisch mailing list <mailto:[email protected]> [email protected] <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. -------------------------------------------------------------------------------------------------------------------------------
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
