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

[Thomas Watteyne <[e-mail]>]

+1 on the open hand

On Thu, Aug 25, 2016 at 1:44 PM, Pascal Thubert (pthubert) <
[e-mail]> 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, 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:[e-mail]]
> *Sent:* jeudi 25 août 2016 13:23
> *To:* Shwetha Bhandari (shwethab) <[e-mail]>
> *Cc:* Lijo Thomas <[e-mail]>; Pascal Thubert (pthubert) <
> [e-mail]>; [e-mail]; Frank Brockners (fbrockne) <
> [e-mail]>
>
> *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) <
> [e-mail]> 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
>
>
>
> Thanks,
>
> Shwetha
>
>
>
> *From: *6tisch <[e-mail]> on behalf of Lijo Thomas <
> [e-mail]>
> *Reply-To: *Lijo Thomas <[e-mail]>
> *Date: *Thursday, August 25, 2016 at 3:37 PM
> *To: *Thomas Watteyne <[e-mail]>, "Pascal Thubert
> (pthubert)" <[e-mail]>
> *Cc: *"[e-mail]" <[e-mail]>
>
>
> *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)" <
> [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] <[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
>
> _______________________________________
>
>
>
>
>
> ------------------------------------------------------------
> -------------------------------------------------------------------
> [ 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
>
> _______________________________________
>



-- 
_______________________________________

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
_______________________________________