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]> 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> > 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]> on behalf of Lijo Thomas < > [email protected]> > Reply-To: Lijo Thomas <[email protected]> > Date: Thursday, August 25, 2016 at 3:37 PM > To: Thomas Watteyne <[email protected]>, "Pascal Thubert > (pthubert)" <[email protected]> > Cc: "[email protected]" <[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]> 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, > 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] <[email protected]>] *On > Behalf Of *Thomas Watteyne > *Sent:* jeudi 25 août 2016 08:28 > *To:* Lijo Thomas <[email protected]> > *Cc:* [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 with the OpenWSN implementation, there is > already an application called rrt which sends the ASN as application > payload at the source, and records the ASN when the DAGroot has received > that. You can then substract one by the other and do some stats. Please ask > further questions to the OpenWSN community [1] as such technical discussion > on a particular implementation doesn't belong on the 6TiSCH WG ML. > > > > If you are using the commercial SmartMesh IP solution by Linear Tech [2], > good news, all of that is already built in. The manager (~DAGroot) keeps > track of timing and can send you average latencies for each of your nodes. > If you're interested, you can look at these numbers "live" on deployments > in Argentina [3,4] or California [5]. As you might imagine, > latency/throughput/lifetime trade-off for one another, so there is a handy > "performance estimator" tool you can use [6,7]. For further question on > this topic, please use www.dustcloud.org. > > > > Finally, looking at lowering latency in 6TiSCH has been an important > research topic in the last year or so. Look for example at the "Low-Latency > Scheduling Function" [8] work which lowers the per-hop latency to 10's of > ms withing the 6TiSCH framework. > > > > Thomas > > > > [1] www.openwsn.org > > [2] www.linear.com/dust > > [3] http://www.savethepeaches.com/ > > [4] PEACH: Predicting Frost Events in Peach Orchards Using IoT Technology. > Thomas Watteyne, Ana Laura Diedrichs, Keoma Brun-Laguna, Javier Emilio > Chaar, Diego Dujovne, Juan Carlos Taffernaberry, Gustavo Mercado. EAI > Endorsed Transactions on the Internet of Things, to appear in 2016. > > [5] http://www.snowhow.io/ > > [6] http://www.linear.com/docs/42452 > > [7] Industrial IEEE802.15.4e Networks: Performance and Trade-offs. Thomas > Watteyne, Joy Weiss, Lance Doherty, Jonathan Simon. IEEE International > Conference on Communications (IEEE ICC), Internet of Things Symposium, > London, UK, 8-12 June 2015. > > [8] LLSF: Low Latency Scheduling Function for 6TiSCH Networks. Tengfei > Chang, Thomas Watteyne, Qin Wang, Xavier Vilajosana. IEEE International > Conference on Distributed Computing in Sensor Systems (DCOSS), Washington, > DC, USA, 26-28 May 2016. > > > > On Thu, Aug 25, 2016 at 7:57 AM, Lijo Thomas <[email protected]> wrote: > > Hi all, > > > > We are working on problem which needs the *Time to Live (TTL) information* > in terms of *ASN * to be included as part of the Packet. > > > > We require the intermediate nodes to update TTL at each hop. > > > > How this information can be passed in a 6tisch framework. > > > > Suggestions are welcome.. > > > > Thanks & Regards > > Lijo Thomas > > > > > > > ------------------------------------------------------------ > ------------------------------------------------------------------- > [ 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 > > > > > -- > > _______________________________________ > > > > 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 > > _______________________________________ > > > > > ------------------------------------------------------------ > ------------------------------------------------------------------- > [ 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. > ------------------------------------------------------------ > ------------------------------------------------------------------- > -- _______________________________________ 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
