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 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 <[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 < > [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 <[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 <[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 > > www.thomaswatteyne.com > _______________________________________ > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > > > > _______________________________________________ > 6tisch mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6tisch > > >
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
