Hi pascal, Thanks for your valuable comments and encouragement.
We will work on the problem and get back. Thanks & Regards Lijo Thomas On August 25, 2016 at 5:14 PM "Pascal Thubert (pthubert)" <[email protected]> wrote: > > Exactly! > > > > Keeping in mind that this is an open hand as opposed to “prove yourself and > come back (expecting not)”. > > > > One path is: define the HbH header option you rneed, see how you can converge > with what Shwetha is showing us (which I was refering to), pick a code that > extends 6LoRH > https://tools.ietf.org/html/draft-ietf-roll-routing-dispatch-00#section-9.2 > <https://tools.ietf.org/html/draft-ietf-roll-routing-dispatch-00#section-9.2> > , work out the compressed form, and go for it with your experimentation… > > > > … and please keep this group in the loop. A personal submissions will not do > harm! > > > > Pascal > > > > From: Thomas Watteyne [mailto:[email protected]] > Sent: jeudi 25 août 2016 13:23 > To: Shwetha Bhandari (shwethab) <[email protected]> > Cc: Lijo Thomas <[email protected]>; Pascal Thubert (pthubert) > <[email protected]>; [email protected]; Frank Brockners (fbrockne) > <[email protected]> > Subject: Re: [6tisch] Time to Live - ASN in a packet > > > > Lijo, > > That's great, indeed. My naive response is that, if you find out that there > is real value in doing this, we will find a way to fit that information > somwhere. > > Looks like Shwetha's pointers go in that direction. Some HbH header seems > suitable, we just have to find a mechanism for matching that those TSCH ASN. > > My recommendation would be to measure/prove the value first, and embark in > standardization after. > > Thomas > > > > On Thu, Aug 25, 2016 at 12:24 PM, Shwetha Bhandari (shwethab) > <[email protected] <mailto:[email protected]> > wrote: > > > > > > Hi Lijo, > > > > > > > > We are trying something similar with In-band OAM – defining HbH options to > > collect timestamps, node, interface information as the packet traverses the > > nodes. Please take a look at the following: > > > > https://tools.ietf.org/html/draft-brockners-inband-oam-data-01#section-3.1 > > <https://tools.ietf.org/html/draft-brockners-inband-oam-data-01> > > > > > > > > https://tools.ietf.org/html/draft-brockners-inband-oam-transport-01#section-3.1 > > <https://tools.ietf.org/html/draft-brockners-inband-oam-transport-01#section-3.1> > > > > > > > > Thanks, > > > > Shwetha > > > > > > > > From: 6tisch <[email protected] <mailto:[email protected]> > > > on behalf of Lijo Thomas <[email protected] <mailto:[email protected]> > > > Reply-To: Lijo Thomas <[email protected] <mailto:[email protected]> > > > Date: Thursday, August 25, 2016 at 3:37 PM > > To: Thomas Watteyne <[email protected] > > <mailto:[email protected]> >, "Pascal Thubert (pthubert)" > > <[email protected] <mailto:[email protected]> > > > Cc: "[email protected] <mailto:[email protected]> " <[email protected] > > <mailto:[email protected]> > > > > > > > Subject: Re: [6tisch] Time to Live - ASN in a packet > > > > > > > > > > Hi Pascal & Thomas, > > > > The problem is inline with Pascal's comment on "looking for per packet > > information to as to monitor and maybe influence the forwarding and > > delivery" > > > > We are proposing a debt based distributed scheduling scheme where nodes > > make forwarding decisions based on the PDR and end-to-end delay requirement > > of flows. > > > > We simulated our algorithm using 6tisch simulator and got encouraging > > results. For this, we plugged in ASN value in the application payload and > > the intermediate node updates the ASN value before forwarding. > > > > Now we are implementing the algorithm on the hardware using OpenWSN > > environment and intend to do inline with the standard. > > > > We are actually contemplating on HbH at L3, similar to RPL RPI as > > described in RFC 6553 > > > > But we would like to understand that if any options is available in the > > 6tisch framework. > > > > Expecting your valuable comments..!!!!!!!!!! > > > > > > > > Thanks & Regards > > > > Lijo Thomas > > > > > > > > > > > > > > On August 25, 2016 at 1:39 PM "Pascal Thubert (pthubert)" > > <[email protected] <mailto:[email protected]> > wrote: > > > > > > > > > > Hello Lijo: > > > > > > > > > > > > Like Thomas, I’d love to understand what your case and solution > > > approach is. Is asynchronous OAM like the openWSN application enough for > > > you? Or else are you looking for per packet information to as to monitor > > > and maybe influence the forwarding and delivery? > > > > > > > > > > > > In the latter case, your work may be related to other efforts, and if > > > your experimentation is successful then why not consider a more general > > > applicability? > > > > > > > > > > > > All in all I have this feeling that time-aware forwarding is on the > > > way, in which exact shape and form is left TBD: > > > > > > - DetNet is discussing validating the end-to-end latency of > > > individual packets to make sure that the delivery was within bounds. Is > > > that similar to your need? > > > > > > - I’ve participated to work where the QoS of the packet was > > > estimated at each hop depending on whether the packet was early or late > > > vs. a predefined schedule. This makes things much simpler but slightly > > > less deterministic than a tight scheduling. > > > > > > - There’s also OAM work that uses HbH headers to monitor the > > > packets as they flow along the network (IOW, in band as opposed to > > > asynchronous OAM packets) > > > > > > > > > > > > My understanding is that you want HbH behavior. > > > > > > - If you are doing a mesh, you can probable hack a mesh header. > > > > > > - But if you are considering a larger applicability (I hope so!) > > > then you probably want to hack at L3. > > > > > > > > > > > > You can find tons of ideas of what can be done at L3 in various > > > environments in https://tools.ietf.org/html/draft-dt-detnet-dp-alt-03 > > > <https://tools.ietf.org/html/draft-dt-detnet-dp-alt-03> , which is pending > > > adoption call. > > > > > > > > > > > > But if you narrow down to 6TiSCH, then you probably want to design you > > > own option in the HbH header and incode it in a 6LoRH similar to the RPL > > > RPI. You may use ASN to start with, but when going standard you’ll have to > > > abstract that a little bit, even if the data in the packet is unchanged. > > > > > > > > > > > > Very keen to hear more! > > > > > > > > > > > > Pascal > > > > > > > > > > > > From: 6tisch [mailto:[email protected] > > > <mailto:[email protected]> ] On Behalf Of Thomas Watteyne > > > Sent: jeudi 25 août 2016 08:28 > > > To: Lijo Thomas <[email protected] <mailto:[email protected]> > > > > Cc: [email protected] <mailto:[email protected]> > > > Subject: Re: [6tisch] Time to Live - ASN in a packet > > > > > > > > > > > > Lijo, > > > > > > > > > > > > It looks like you are describing two things: the TTL (or hop limit in > > > IPv6 parlance) which decrements by one by each router, and some timestamp > > > which can be used to measure end -to-end latency. I'm assuming the latter. > > > > > > > > > > > > I'm also assuming you are doing this as part of an experiment, to look > > > at the end-to-end/hop-by-hop latency. In that context, you probably aren't > > > looking for standardizing that (or even standards-compliance during your > > > experiment), but more at an implementation technique to keep that > > > information. > > > > > > > > > > > > Of course, the answer depends entirely on the information we are > > > missing. But assuming you are playing wetf.org/mailman/listinfo/6tisch" > > > target="_blank">https://www.ietf.org/mailman/listinfo/6tisch > > > > > > > > > > > > > > > > > > -- > > > > _______________________________________ > > > > > > > > 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 <http://www.thomaswatteyne.com> > > > > _______________________________________ > > > > > > > > > > > ------------------------------------------------------------------------------------------------------------------------------- > [ C-DAC is on Social-Media too. Kindly follow us at: > Facebook: https://www.facebook.com/CDACINDIA > <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. > > ------------------------------------------------------------------------------------------------------------------------------- > -- _______________________________________ 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 <http://www.thomaswatteyne.com> _______________________________________ ------------------------------------------------------------------------------------------------------------------------------- [ 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
