Re: [6tisch] Time to Live - ASN in a packet

[Thomas Watteyne <[e-mail]>]

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) <
[e-mail]> 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:[e-mail]] *On Behalf Of *Thomas
> Watteyne
> *Sent:* jeudi 25 août 2016 08:28
> *To:* Lijo Thomas <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]> 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
> [e-mail]
> 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
_______________________________________