Lijjo, One quick idea. If you are running on a testbed (e.g. https://www.iot-lab.info/), you could print the timestamp of when a packet passes through the nodes over their serial port.
Thomas On Thu, Aug 25, 2016 at 10:09 AM, 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]] *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 > > _______________________________________ > -- _______________________________________ 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
