Shwetha, I fail to understand how this option would be carried. I assume a hop-by-hop IPv6 extension header? Thomas
On Wednesday, August 31, 2016, Lijo Thomas <[email protected]> wrote: > Hi all, > > > > This is for your information. > > > > Following are the mail interactions with Shwetha regarding the subject > > > > Further inputs on the topic are most welcome.. > > > Thanks & Regards > > Lijo Thomas > > > > > -------- Forwarded Message -------- > > *Subject: * > > Re: [6tisch] Time to Live - ASN in a packet > > *Date: * > > Fri, 26 Aug 2016 18:29:34 +0530 (IST) > > *From: * > > Lijo Thomas <[email protected]> <javascript:_e(%7B%7D,'cvml','[email protected]');> > > *Reply-To: * > > Lijo Thomas <[email protected]> <javascript:_e(%7B%7D,'cvml','[email protected]');> > > *To: * > > Shwetha Bhandari (shwethab) <[email protected]> > <javascript:_e(%7B%7D,'cvml','%[email protected]%5Cx3e');> > > > > > > Hi Shwetha, > > > > Your proposal sounds good ! > > > > Since the intermediate nodes does not have to modify the packet, your > suggestion suits the constrained environments as well. > > > > Thanks & Regards > > Lijo Thomas > > > On August 26, 2016 at 2:14 PM "Shwetha Bhandari (shwethab)" > <[email protected]> <javascript:_e(%7B%7D,'cvml','[email protected]');> > wrote: > > Hi Lijo, > > > > Very interesting use case, thanks for sharing the details. > > > > So at a minimum you will need to: > > - timestamp when the packet starts its journey in the deterministic > domain > - A threshold delay that is acceptable > > The above can be expressed as a future timestamp that specifies the cutoff > time to deliver the packet to its destination. > > > > Given this, the intermediate hops need not update the value, but only read > it to check the time remaining as the clocks are synchronized. > > Is that a fair assumption? > > > > If yes perhaps we can define a new type of Edge to Edge option that we > have defined here - https://tools.ietf.org/html/ > draft-brockners-inband-oam-data-01#section-3.3 > > That will include the [timestamp + max delay] at the originator and be > examined at every hop and used for scheduling. > > Something like: > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Option Type | Opt Data Len | OAM-E2E-Type | reserved | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | E2E Option data format determined by iOAM-E2E-Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > iOAM-E2E-Type: 8-bit identifier of a particular in-band OAM E2E > > variant. > > 0: E2E option data is a 64-bit sequence number added to a > > specific tube which is used to identify packet loss and > > reordering for that tube. > > 1: E2E option data is a 64-bit timestamp ….. > > > > > > Thoughts? > > > > Thanks, > > Shwetha > > > > > > *From: *Lijo Thomas < [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Reply-To: *Lijo Thomas < [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Date: *Friday, August 26, 2016 at 11:59 AM > *To: *Shwetha bhandari < [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Cc: *"Frank Brockners (fbrockne)" < [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>>, " > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>" < > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>>, " > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>" < > [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Subject: *Re: [6tisch] Time to Live - ASN in a packet > > > > Hi Shwetha, > > Thanks for the very useful inputs! > > I thought I will briefly describe the context. > > We are implementing a distributed scheduling scheme on a 6tisch network to > support flows with strict delay contstaints. In some sense, we are working > on > deterministic networking. As you might be aware, there are several > distributed > algorithms in the literature such as EDF, LLF and so forth where > intermediate > nodes schedules packets based on the per-flow delay requirements, > remaining > time left to reach the destination, delay already experienced. These > distributed debt based schemes attempt to meet the deadlines of the flows, > thereby enabling us to realise deterministic networks. > > Therefore, the scheduler running on the nodes need to know the remaining > time > left before which the packet should reach the receiver. Since the 6tisch > network is time synchronized, we are thinking of using ASN as a means to > update the remaining time left. The originator specifies the maximum time > limit. > > I went through your draft. Thanks for the same! From my understanding, it > appears that we may have to use OAM-trace-type : 0x00001001 for our > requirement. > > I am not sure if the above type can be used in our problem setting. > > Hence I would like to know if there is any specfic format explicitly > defined > considering the case of LLNs for including the Time field in hop by hop > header, > something similar to inclusion of RPL packet information in HbH. > > I would like to discuss more on this topic if you feel it is interesting. > > > > Thanks & Regards > > Lijo Thomas > > > > > > > On August 26, 2016 at 5:44 AM "Shwetha Bhandari (shwethab)" < > [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> > wrote: > > Hi Lijo, > > > > We have the implementation in VPP <http://wiki.fd.io/view/VPP>, you can > refer to the code here > <https://gerrit.fd.io/r/gitweb?p=vpp.git;a=blob;f=vnet/vnet/ip/ip6_hop_by_hop.c;h=7038556848c3d325b6612678a903f26cbf671de5;hb=HEAD>. > > > If you want to try it out in your experiment do let us know we can help > with more documentation to bring it up. > > > > We have some of our demos available here > <https://www.youtube.com/channel/UC0WJOAKBTrftyosP590RrXw>. > > Do keep us posted on the hardware study and any modification that you try > for constrained environment. > > > > Thanks, > > Shwetha > > > > *From: *Lijo Thomas < [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Reply-To: *Lijo Thomas < [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Date: *Thursday, August 25, 2016 at 5:48 PM > *To: *Shwetha bhandari < [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Cc: *"Frank Brockners (fbrockne)" < [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Subject: *Re: [6tisch] Time to Live - ASN in a packet > > > > Hi Shwetha, > > > > Excellent.. > > > > Thanks for the inputs, we are looking for a solution exactly suggested by > you. > > > > we are implementing our algorithm on hardware and will get back to you . > > > > Thanks & Regards > > Lijo Thomas > > > > > > > On August 25, 2016 at 3:54 PM "Shwetha Bhandari (shwethab)" < > [email protected] <javascript:_e(%7B%7D,'cvml','[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 > > > > Thanks, > > Shwetha > > > > *From: *6tisch < [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> on behalf of > Lijo Thomas < [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>> > > *Reply-To: *Lijo Thomas < [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Date: *Thursday, August 25, 2016 at 3:37 PM > *To: *Thomas Watteyne < [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>>, "Pascal > Thubert (pthubert)" < [email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Cc: *" [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');>" > < [email protected] <javascript:_e(%7B%7D,'cvml','[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] <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[email protected]');>] *On Behalf Of > *Thomas > Watteyne > *Sent:* jeudi 25 août 2016 08:28 > *To:* Lijo Thomas <[email protected] > <javascript:_e(%7B%7D,'cvml','[email protected]');>> > *Cc:* [email protected] <javascript:_e(%7B%7D,'cvml','[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] > <javascript:_e(%7B%7D,'cvml','[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] <javascript:_e(%7B%7D,'cvml','[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. > ------------------------------------------------------------ > ------------------------------------------------------------------- > > > _______________________________________________ > 6tisch mailing list > [email protected] <javascript:_e(%7B%7D,'cvml','[email protected]');> > https://www.ietf.org/mailman/listinfo/6tisch > > > ------------------------------------------------------------ > ------------------------------------------------------------------- > [ 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. > ------------------------------------------------------------ > ------------------------------------------------------------------- > > > > > > ------------------------------------------------------------ > ------------------------------------------------------------------- > [ 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. > ------------------------------------------------------------ > ------------------------------------------------------------------- > > > > > > ------------------------------------------------------------ > ------------------------------------------------------------------- > [ 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. > ------------------------------------------------------------ > ------------------------------------------------------------------- > > > > ------------------------------------------------------------ > ------------------------------------------------------------------- > [ 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
