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

From: "Shwetha Bhandari (shwethab)" <[email-masked]>
Date: Thu, 8 Sep 2016 10:21:01 +0000

Hi Thomas,

Yes, if it is v6 then hbh option -
 https://tools.ietf.org/html/draft-brockners-inband-oam-transport-01#section-3.1

For Lijo’s use-case the below proposal was to define a new type in hbh option defined here - https://tools.ietf.org/html/draft-brockners-inband-oam-data-01#section-3.3

Thanks,
Shwetha
From: Thomas Watteyne <[email-masked]<mailto:[email-masked]>>
Date: Thursday, September 8, 2016 at 3:47 PM
To: Lijo Thomas <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Shwetha bhandari <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6tisch] Time to Live - ASN in a packet

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-masked]<mailto:[email-masked]>> 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-masked]><javascript:_e(%7B%7D,'cvml',[email-masked]');>

Reply-To:

Lijo Thomas <[email-masked]><javascript:_e(%7B%7D,'cvml',[email-masked]');>

To:

Shwetha Bhandari (shwethab) <[email-masked]><javascript:_e(%7B%7D,'cvml',[email-masked]%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-masked]><javascript:_e(%7B%7D,'cvml',[email-masked]');> 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-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Reply-To: Lijo Thomas < [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Date: Friday, August 26, 2016 at 11:59 AM
To: Shwetha bhandari < [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Cc: "Frank Brockners (fbrockne)" < [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>, " [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>" < [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>, " [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>" < [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
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-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> 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-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Reply-To: Lijo Thomas < [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Date: Thursday, August 25, 2016 at 5:48 PM
To: Shwetha bhandari < [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Cc: "Frank Brockners (fbrockne)" < [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
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-masked]<javascript:_e(%7B%7D,'cvml',[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

From: 6tisch < [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>> on behalf of Lijo Thomas < [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Reply-To: Lijo Thomas < [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Date: Thursday, August 25, 2016 at 3:37 PM
To: Thomas Watteyne < [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>, "Pascal Thubert (pthubert)" < [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Cc: " [email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>" < [email-masked]<javascript:_e(%7B%7D,'cvml',[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.
Expecting your valuable comments..!!!!!!!!!!

Thanks & Regards
Lijo Thomas

On August 25, 2016 at 1:39 PM "Pascal Thubert (pthubert)" < [email-masked]<javascript:_e(%7B%7D,'cvml',[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)

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]<javascript:_e(%7B%7D,'cvml',[email-masked]');>] On Behalf Of Thomas Watteyne
Sent: jeudi 25 août 2016 08:28
To: Lijo Thomas <[email-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Cc: [email-masked]<javascript:_e(%7B%7D,'cvml',[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]<javascript:_e(%7B%7D,'cvml',[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.

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-masked]<javascript:_e(%7B%7D,'cvml',[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<http://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-masked]<javascript:_e(%7B%7D,'cvml',[email-masked]');>
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<http://www.thomaswatteyne.com>
_______________________________________

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 8 Sep 2016 12:24:04 +0200

I understand now, thanks.

On Thursday, September 8, 2016, Shwetha Bhandari (shwethab) <
[email-masked]> wrote:

> For Lijo’s use-case the below proposal was to define a new type in hbh
> option defined here - https://tools.ietf.org/html/
> draft-brockners-inband-oam-data-01#section-3.3
>
> Thanks,
> Shwetha
> From: Thomas Watteyne <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> To: Lijo Thomas <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> Cc: "[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>" <
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>,
> Shwetha bhandari <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> On Wednesday, August 31, 2016, Lijo Thomas <[email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> wrote:
>
>> Hi all,
>>
>>
>>
>> *Subject: *
>> *Date: *
>> *From: *
>> Lijo Thomas <[email-masked]>
>>
>> *Reply-To: *
>>
>> Lijo Thomas <[email-masked]>
>>
>> *To: *
>>
>> Shwetha Bhandari (shwethab) <[email-masked]>
>>
>>
>>
>>
>>
>> Hi Shwetha,
>>
>>
>>
>> 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-masked]> wrote:
>>
>> Hi Lijo,
>>
>>
>>
>>    - 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.
>>
>> If yes perhaps we can define a new type of Edge to Edge option that we
>> have defined here -  https://tools.ietf.org/html/dr
>> aft-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
>>
>> *From: *Lijo Thomas < [email-masked]>
>> *Reply-To: *Lijo Thomas < [email-masked]>
>> *Date: *Friday, August 26, 2016 at 11:59 AM
>> *To: *Shwetha bhandari < [email-masked]>
>> *Cc: *"Frank Brockners (fbrockne)" < [email-masked]>, "
>> [email-masked]" < [email-masked]>, "
>> [email-masked]" < [email-masked]>
>> *Subject: *Re: [6tisch] Time to Live - ASN in a packet
>>
>>
>>
>> Hi Shwetha,
>>
>> On August 26, 2016 at 5:44 AM "Shwetha Bhandari (shwethab)" <
>> [email-masked]> 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>.
>>
>>
>> We have some of our demos available here
>> <https://www.youtube.com/channel/UC0WJOAKBTrftyosP590RrXw>.
>>
>> *From: *Lijo Thomas < [email-masked]>
>> *Reply-To: *Lijo Thomas < [email-masked]>
>> *Date: *Thursday, August 25, 2016 at 5:48 PM
>> *To: *Shwetha bhandari < [email-masked]>
>> *Cc: *"Frank Brockners (fbrockne)" < [email-masked]>
>> *Subject: *Re: [6tisch] Time to Live - ASN in a packet
>>
>>
>>
>> Hi Shwetha,
>>
>>
>>
>> Excellent..
>>
>>
>>
>> On August 25, 2016 at 3:54 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#section-3.1
>> <https://tools.ietf.org/html/draft-brockners-inband-oam-data-01>
>>
>> *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
>> (pthubert)" < [email-masked]>
>> *Cc: *" [email-masked]" < [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.
>>
>> 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?
>>
>>
>>
>> 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,
>>
>>
>>
>> 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
>>
>> [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.
>>
>> [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.
>>
>>
>>
>> ------------------------------------------------------------
>> -------------------------------------------------------------------
>> ------------------------------------------------------------
>> -------------------------------------------------------------------
>>
>>
>> [email-masked]
>> www.thomaswatteyne.com
>> ------------------------------------------------------------
>> -------------------------------------------------------------------
>> ------------------------------------------------------------
>> -------------------------------------------------------------------
>>
>>
>> [email-masked]
>> ------------------------------------------------------------
>> -------------------------------------------------------------------
>> ------------------------------------------------------------
>> -------------------------------------------------------------------
>>
>>
>>
>>
>>
>> ------------------------------------------------------------
>> -------------------------------------------------------------------
>> ------------------------------------------------------------
>> -------------------------------------------------------------------
>>
>>
>>
>>
>>
>> ------------------------------------------------------------
>> -------------------------------------------------------------------
>> ------------------------------------------------------------
>> -------------------------------------------------------------------
>>
>>
>>
>> ------------------------------------------------------------
>> -------------------------------------------------------------------
>> ------------------------------------------------------------
>> -------------------------------------------------------------------
>>
>
>
> --
> www.thomaswatteyne.com

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: Thomas Watteyne <[email-masked]>
Date: Thu, 8 Sep 2016 12:17:23 +0200

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-masked]> wrote:

> Lijo Thomas <[email-masked]> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>
> *Reply-To: *
>
> Lijo Thomas <[email-masked]> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
>
> *To: *
>
> <javascript:_e(%7B%7D,'cvml',[email-masked]%5Cx3e');>
>
>
>
>
>
> Hi Shwetha,
>
>
>
> <[email-masked]> <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> wrote:
>
> Hi Lijo,
>
>
>
> 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.
>
> have defined here -  https://tools.ietf.org/html/
> *From: *Lijo Thomas < [email-masked]
> *Reply-To: *Lijo Thomas < [email-masked]
> *To: *Shwetha bhandari < [email-masked]
> *Cc: *"Frank Brockners (fbrockne)" < [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, "
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>" <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, "
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>" <
> [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> wrote:
>
> Hi Lijo,
>
>
>
> *From: *Lijo Thomas < [email-masked]
> *Reply-To: *Lijo Thomas < [email-masked]
> *To: *Shwetha bhandari < [email-masked]
> *Cc: *"Frank Brockners (fbrockne)" < [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[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
> *From: *6tisch < [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>> on behalf of
> Lijo Thomas < [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
>
> *Reply-To: *Lijo Thomas < [email-masked]
> *To: *Thomas Watteyne < [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>, "Pascal
> Thubert (pthubert)" < [email-masked]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> *Cc: *" [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>"
> < [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> wrote:
>
> Hello Lijo:
>
>
>
> 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?
>
>
>
> 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]
> <javascript:_e(%7B%7D,'cvml',[email-masked]');>] *On Behalf Of *Thomas
> Watteyne
> *To:* Lijo Thomas <[email-masked]
> *Cc:* [email-masked] <javascript:_e(%7B%7D,'cvml',[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.
>
>
>
> [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.
>
> On Thu, Aug 25, 2016 at 7:57 AM, Lijo Thomas <[email-masked]
> 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.
>
>
>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>

Thomas Watteyne, PhD

www.thomaswatteyne.com

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 8 Sep 2016 10:29:42 +0000

Hello Thomas :

I’d suspect so, and we’d use a 6LoRH header to compress it.

Take care,

Pascal

From: 6tisch [mailto:[email-masked]] On Behalf Of Thomas Watteyne
Sent: jeudi 8 septembre 2016 12:17
To: Lijo Thomas <[email-masked]>
Cc: [email-masked]; Shwetha Bhandari (shwethab) <[email-masked]>
Subject: Re: [6tisch] Time to Live - ASN in a packet

Shwetha,

Thanks & Regards
Lijo Thomas

-------- Forwarded Message --------
Subject:

Date:

From:

Reply-To:

To:

Hi Shwetha,

Thanks & Regards
Lijo Thomas

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.

       0                   1                   2                   3

      variant.

Thoughts?

Thanks,

Shwetha

Hi Shwetha,

Thanks & Regards
Lijo Thomas

Thanks,
Shwetha

Hi Shwetha,

Excellent..

Thanks & Regards
Lijo Thomas

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: Michael Richardson <[email-masked]>
Date: Thu, 08 Sep 2016 09:17:56 -0400

> For Lijo’s use-case the below proposal was to define a new type in hbh option
    > defined here -
    > https://tools.ietf.org/html/draft-brockners-inband-oam-data-01#section-3.3

1) make sure the option is set to be ignored if not understood.
2) when adding the option, an IPIP header is needed, so this will affect
   compression rates if an IPIP header isn't already required for another
   RPL artifact.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-