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

From: Lijo Thomas <[email-masked]>
Date: Thu, 25 Aug 2016 11:27:17 +0530 (IST)

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.
-------------------------------------------------------------------------------------------------------------------------------

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 25 Aug 2016 08:27:32 +0200

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-masked]> 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.
>
> ------------------------------------------------------------
> -------------------------------------------------------------------
> ------------------------------------------------------------
> -------------------------------------------------------------------
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> 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
_______________________________________

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 25 Aug 2016 08:09:05 +0000

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-masked]] On Behalf Of Thomas Watteyne
Sent: jeudi 25 août 2016 08:28
To: Lijo Thomas <[email-masked]>
Cc: [email-masked]
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<http://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<http://www.openwsn.org>
[2] www.linear.com/dust<http://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-masked]<mailto:[email-masked]>> 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.

Thanks & Regards
Lijo Thomas

_______________________________________________
6tisch mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6tisch

Thomas Watteyne, PhD

www.thomaswatteyne.com<http://www.thomaswatteyne.com>
_______________________________________

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 25 Aug 2016 10:27:11 +0200

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-masked]> 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)
>
>
>
> 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-masked]] *On Behalf Of *Thomas
> Watteyne
> *Sent:* jeudi 25 août 2016 08:28
> *To:* Lijo Thomas <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [6tisch] Time to Live - ASN in a packet
>
>
>
> Lijo,
>
>
>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Lijo Thomas <[email-masked]>
Date: Thu, 25 Aug 2016 15:37:38 +0530 (IST)

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-masked]>
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?
> 
> 
> 
>  -        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)
> 
> 
> 
>  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
> <https://tools.ietf.org/html/draft-dt-detnet-dp-alt-03> , which is pending
> adoption call.
> 
> 
> 
> 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
> 
> 
> 
> 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.
> 
> 
> 
> 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 <http://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 <http://www.openwsn.org>
> 
>  [2] www.linear.com/dust <http://www.linear.com/dust>
> 
>  [3] http://www.savethepeaches.com/ <http://www.savethepeaches.com/>
> 
> 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/ <http://www.snowhow.io/>
> 
>  [6] http://www.linear.com/docs/42452 <http://www.linear.com/docs/42452>
> 
> 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-masked]
> <mailto:[email-masked]> > 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.
> > 
> > 
> > 
> >   Facebook: https://www.facebook.com/CDACINDIA
> > <https://www.facebook.com/CDACINDIA> & Twitter: @cdacindia ]
> > 
> >   [email-masked] <mailto:[email-masked]>
> > <https://www.ietf.org/mailman/listinfo/6tisch>
> > 
> >  > 
> 
> 
> 
>  --
> 
>  www.thomaswatteyne.com <http://www.thomaswatteyne.com>
>

---

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Thu, 25 Aug 2016 10:24:01 +0000

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-masked]<mailto:[email-masked]>> on behalf of Lijo Thomas <[email-masked]<mailto:[email-masked]>>
Reply-To: Lijo Thomas <[email-masked]<mailto:[email-masked]>>
Date: Thursday, August 25, 2016 at 3:37 PM
To: Thomas Watteyne <[email-masked]<mailto:[email-masked]>>, "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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.

Thanks & Regards
Lijo Thomas

On August 25, 2016 at 1:39 PM "Pascal Thubert (pthubert)" <[email-masked]<mailto:[email-masked]>> wrote:
Hello Lijo:

Very keen to hear more!

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: jeudi 25 août 2016 08:28
To: Lijo Thomas <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [6tisch] Time to Live - ASN in a packet

Lijo,

Thomas

Thanks & Regards
Lijo Thomas

Thomas Watteyne, PhD

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 25 Aug 2016 13:23:21 +0200

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-masked]> 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-masked]> on behalf of Lijo Thomas <
> [email-masked]>
> Reply-To: Lijo Thomas <[email-masked]>
> To: Thomas Watteyne <[email-masked]>, "Pascal Thubert
> (pthubert)" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
>
> 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.
>
> On August 25, 2016 at 1:39 PM "Pascal Thubert (pthubert)" <
> *From:* 6tisch [mailto:[email-masked] <[email-masked]>] *On
> Behalf Of *Thomas Watteyne

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 25 Aug 2016 11:44:43 +0000

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:[email-masked]]
Sent: jeudi 25 août 2016 13:23
To: Shwetha Bhandari (shwethab) <[email-masked]>
Cc: Lijo Thomas <[email-masked]>; Pascal Thubert (pthubert) <[email-masked]>; [email-masked]; Frank Brockners (fbrockne) <[email-masked]>
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) <[email-masked]<mailto:[email-masked]>> 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

Hi Pascal & Thomas,

Thanks & Regards
Lijo Thomas

Very keen to hear more!

Pascal

Lijo,

Thomas

Thanks & Regards
Lijo Thomas

Thomas Watteyne, PhD

Thomas Watteyne, PhD

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 25 Aug 2016 14:03:13 +0200

+1 on the open hand

On Thu, Aug 25, 2016 at 1:44 PM, Pascal Thubert (pthubert) <
[email-masked]> wrote:

> 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…
>
>
>
> *From:* Thomas Watteyne [mailto:[email-masked]]
> *Sent:* jeudi 25 août 2016 13:23
> *To:* Shwetha Bhandari (shwethab) <[email-masked]>
> *Cc:* Lijo Thomas <[email-masked]>; Pascal Thubert (pthubert) <
> [email-masked]>; [email-masked]; Frank Brockners (fbrockne) <
> [email-masked]>
>
> 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.
>
> *From: *6tisch <[email-masked]> on behalf of Lijo Thomas <
> [email-masked]>
> *Reply-To: *Lijo Thomas <[email-masked]>
> *Date: *Thursday, August 25, 2016 at 3:37 PM
> *To: *Thomas Watteyne <[email-masked]>, "Pascal Thubert
> *Cc: *"[email-masked]" <[email-masked]>
>
>
> *Subject: *Re: [6tisch] Time to Live - ASN in a packet
>
>
>
>
> Hi Pascal & Thomas,
>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Lijo Thomas <[email-masked]>
Date: Thu, 25 Aug 2016 17:40:55 +0530 (IST)

Hi pascal,

Thanks for your valuable comments and encouragement.

We will work on the problem and  get back.

Thanks & Regards
Lijo Thomas

On August 25, 2016 at 5:14 PM "Pascal Thubert (pthubert)" <[email-masked]>
wrote:

>  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
> <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…
> 
> 
> 
>  Cc: Lijo Thomas <[email-masked]>; Pascal Thubert (pthubert)
> <[email-masked]>; [email-masked]; Frank Brockners (fbrockne)
> <[email-masked]>
>  On Thu, Aug 25, 2016 at 12:24 PM, Shwetha Bhandari (shwethab)
> <[email-masked] <mailto:[email-masked]> > wrote:
> 
>   > > 
> >   Hi Lijo,
> > 
> > 
> > 
> >   From: 6tisch <[email-masked] <mailto:[email-masked]> >
> > on behalf of Lijo Thomas <[email-masked] <mailto:[email-masked]> >
> >   Reply-To: Lijo Thomas <[email-masked] <mailto:[email-masked]> >
> >   To: Thomas Watteyne <[email-masked]
> > <mailto:[email-masked]> >, "Pascal Thubert (pthubert)"
> > <[email-masked] <mailto:[email-masked]> >
> >   Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked]
> > <mailto:[email-masked]> >
> > 
> > 
> >   On August 25, 2016 at 1:39 PM "Pascal Thubert (pthubert)"
> > <[email-masked] <mailto:[email-masked]> > 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:
> > > 
> > > 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.
> > > 
> > > environments in https://tools.ietf.org/html/draft-dt-detnet-dp-alt-03
> > >    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
> > >    From: 6tisch [mailto:[email-masked]
> > > <mailto:[email-masked]> ] On Behalf Of Thomas Watteyne
> > >    To: Lijo Thomas <[email-masked] <mailto:[email-masked]> >
> > >    Cc: [email-masked] <mailto:[email-masked]>
> > >    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
> > >    Of course, the answer depends entirely on the information we are
> > > missing. But assuming you are playing wetf.org/mailman/listinfo/6tisch"
> > > target="_blank">https://www.ietf.org/mailman/listinfo/6tisch
> > > 
> > >   > > 
> > 
> > 
> > 
> > 
> >   --
> > 

--

Thomas Watteyne, PhD

Co-chair, IETF 6TiSCH