Subject: [6lo] IETF 97 : Comments : draft-lijo-6lo-expiration-time-00.txt

From: "Lijo Thomas" <[email-masked]>
Date: Tue, 22 Nov 2016 10:23:31 +0530

Hi Thomas,
 
Thanks for your valuable comments during the draft <draft-lijo-6lo-expiration-time-00> IETF97 presentation
 
Your suggestion of including packet origination time along with the expiration time is very nice, as it conveys  very useful information to the intermediate nodes as well as the receiver to know how much time has already been elapsed. We will update the draft based on your suggestion. 
 
But I foresee an interesting problem when we include the packet origination time. While it is straightforward when the source and destination belong to the same time zone, it is tricky if they belong to different time zones, as the origination time will be invalid once the packet crosses over to network segments with different time zones. For instance, when the packet traverses across  2 LBRs belonging to different 6TiSCH networks due to different ASN time spaces. We plan to discuss our resolution to such scenarios in our draft.
  
Suggestions are most welcome !!!!

Thanks & Regards,
Lijo Thomas 
 
From: 6lo [ <mailto:[email-masked]> mailto:[email-masked]] On Behalf Of Lijo Thomas
Sent: 29 October 2016 14:35
To:  <mailto:[email-masked]> [email-masked]
Subject: [6lo] Fwd: New Version Notification for draft-lijo-6lo-expiration-time-00.txt
 
Hi all,
We have submitted a new draft t <draft-lijo-6lo-expiration-time-00.txt> which proposes a new 6LoWPAN routing header type for conveying packet expiration time information.
  <https://www.ietf.org/internet-drafts/draft-lijo-6lo-expiration-time-00.txt> https://www.ietf.org/internet-drafts/draft-lijo-6lo-expiration-time-00.txt
Your comments are highly appreciated.
 
Regards
Lijo Thomas

---------- Original Message ---------- 
From:  <mailto:[email-masked]> [email-masked] 
To: "S.V.R Anand" < <mailto:[email-masked]> [email-masked]>, Satish Anamalamudi < <mailto:[email-masked]> [email-masked]>, Lijo Thomas < <mailto:[email-masked]> [email-masked]>, "P.M. Akshay" < <mailto:[email-masked]> [email-masked]>, Malati Hegde < <mailto:[email-masked]> [email-masked]>, Charles Perkins < <mailto:[email-masked]> [email-masked]> 
Date: October 29, 2016 at 11:43 AM 
Subject: New Version Notification for draft-lijo-6lo-expiration-time-00.txt 

A new version of I-D, draft-lijo-6lo-expiration-time-00.txt 
has been successfully submitted by Lijo Thomas and posted to the 
IETF repository. 

Name: draft-lijo-6lo-expiration-time 
Revision: 00 
Title: Packet expiration time in 6LoWPAN Routing Header 
Document date: 2016-10-28 
Group: Individual Submission 
Pages: 11 
URL:  <https://www.ietf.org/internet-drafts/draft-lijo-6lo-expiration-time-00.txt> https://www.ietf.org/internet-drafts/draft-lijo-6lo-expiration-time-00.txt 
Status:  <https://datatracker.ietf.org/doc/draft-lijo-6lo-expiration-time/> https://datatracker.ietf.org/doc/draft-lijo-6lo-expiration-time/ 
Htmlized:  <https://tools.ietf.org/html/draft-lijo-6lo-expiration-time-00> https://tools.ietf.org/html/draft-lijo-6lo-expiration-time-00 

Abstract: 
This document specifies a new type to the 6LoWPAN Dispatch Page 1 
[I-D.ietf-roll-routing-dispatch] for carrying the expiration time of 
data packets within the 6LoWPAN routing header. The expiration time 
is useful in making forwarding and scheduling decisions for time 
critical IoT M2M applications that need deterministic delay 
guarantees over constrained networks and operate within time- 
synchronized networks. 

Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org. 

The IETF Secretariat 

------------------------------------------------------------------------------------------------------------------------------- 
[ C-DAC is on Social-Media too. Kindly follow us at: 
Facebook:  <https://www.facebook.com/CDACINDIA> 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.
-------------------------------------------------------------------------------------------------------------------------------

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 22 Nov 2016 23:02:12 -0500

"Lijo Thomas" <[email-masked]> writes:
> But I foresee an interesting problem when we include the packet
> origination time. While it is straightforward when the source and
> destination belong to the same time zone, it is tricky if they belong
> to different time zones, as the origination time will be invalid once
> the packet crosses over to network segments with different time
> zones. For instance, when the packet traverses across  2 LBRs
> belonging to different 6TiSCH networks due to different ASN time
> spaces. We plan to discuss our resolution to such scenarios in our
> draft.

One general question which is not clear to me is whether this draft only
applies to 6tisch networks, or whether it applies to a broader class of
networks but is used in 6tisch networks slilghtly differently than in
other networks.  (I realize that this may be clear to everyone else from
context, but I am new to the WG.  But I think this point may trip up
inexperienced readers.)

--

What you say above is true, but the -00 version proposes to have the
header contain the expiration time, measured in microseconds after
ASN=0, which has the same difficulty -- if the packet is forwarded to a
different zone, the expiration time must be recalculated and stated
relative to a different epoch.  And -00 describes these recalculations
in the example Case 3 in section 5.  Or at least, Case 3 describes a
version of these calculations, as that text seems to assume that the
header contains a count of time until expiration, not the expiration
time relative to an epoch.

--

Though I believe that there is a lack of clarity in section 4 related to
the fact that the header contains an expiration time relative to an
epoch.  The header is named "Timestamp", which is a term usually used to
describe time-of-origin.  An alternative would be "Expiration", but that
word often means that the packet MUST be dropped at the indicated time.
A word I like is "Deadline", which implies that the network is required
to deliver the packet by the indicated time.

The last two sentences of the first paragraph in section 4 are

   In this specification, the packet origination time is
   represented in microseconds.  In the case of 6tisch networks which is
   explained below, the origination time is the current ASN
   [I-D.vilajosana-6tisch-minimal] converted into microseconds.

This is correct, but not fundamentally important, since origination time
is not carried in the header.  I wonder if you meant to say

   In this specification, the packet expiration time is
   represented in microseconds.  In the case of 6tisch networks which is
   explained below, the expiration time is the current ASN
   [I-D.vilajosana-6tisch-minimal] converted into microseconds.

or maybe better

   ... the expiration time is measured in microseconds from ASN=0.

The following text in section 4 is correct but seems to me to not
emphasize the correct aspects of the situation

   Since the maximum allowable
   transmission delay is specific to each application, the expiration
   time is of variable length.

   Example: In a 6TiSCH network let the time-slot length be 10ms.  If
   the packet_origination_time = Current ASN is 200, and the
   max_allowable_delay is 1 second, then:

      expiration_time = packet_origination_time + max_allowable_delay
      = 200*10ms + 1 second
      = 3 * 10^6 microseconds

   This expiration time requires 22 bits, or 3 octets, in length.  The
   Size is represented as x0011.

The length of the expiration time field is more affected by the ASN than
by the max_allowable_delay.  More realistic is to say

   Since the magnitude of ASN is variable, the expiration time is of
   variable length.

   Example: In a 6TiSCH network let the time-slot length be 10ms.  If
   the network has been operational for 2 years, the
   packet_origination_time = Current ASN is 6,307,200,000, and the
   max_allowable_delay is 1 second, then:

      expiration_time = packet_origination_time + max_allowable_delay
                      = 6,307,200,000*10 ms + 1 second
                      = 63,072,001,000,000 microseconds

   This expiration time requires 46 bits, or 6 octets, to express.  The
   Size is represented as x0100.

--

Section 4 describes the header as an elective 6LoRH header.  As such,
the IANA Considerations should allocate a 6LoRH Type from the Elective
6LoWPAN Routing Header Type registry
(draft-ietf-roll-routing-dispatch-05, section 10.1), not the 6LoWPAN
Dispatch Page1 number space as stated in section 6.

--

In section 3, the description of the TSE field (bits 3 to 7 of the first
byte) does not agree with the description in
draft-ietf-roll-routing-dispatch-05, which specifies that these bits
must be the length of the header.  Technologically, the length of the
expiration time header must be encoded in a way independent of the
header type, as the header is elective and nodes that do not understand
it must be able to ignore it.

--

In section 1, "RPI" is used in one place where "RPL" seems to be intended.

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 23 Nov 2016 22:52:43 -0500

To me, it would be natural to specify an expiration time as the
time-to-expiration, measured in slot times.
draft-lijo-6lo-expiration-time-00 specifies expiration time as an
absolute time, measured from ASN=0 in microseconds.  The latter approach
seems to require larger headers, without making processing much simpler.

It seems to me that measuring expriation time in microseconds is no more
useful than measuring it in slot times, because there is no functional
difference between any of the 10,000 microseconds within a single 10 ms
slot time.  But counting microseconds requires an additional 13 bits
(over 1.5 octets) in the header.

Specifying time-to-expiration means that every time the packet is
forwarded, the expiration header must be updated.  But it can make the
expiration header shorter.  For instance, in the example I mentioned in
my previous message,

or

      expiration_time = ASN 6,307,200,100

Expressing the absolute expiration time in slot times requires 33 bits/5
octets.  But the time-to-expiration is only 100 and can be expressed in
7 bits/1 octet.

Dale

---

From: "Lijo Thomas" <[email-masked]>
Date: Thu, 24 Nov 2016 20:07:07 +0530

Hi Dale,

Thanks a ton for your great suggestions and valuable inputs.!!!

We really appreciate the time you spend for the review. :-)

I have made our comments in line " [LT] : " with your queries below.

Hope you will find an interesting read. Waiting for your further comments..

Thanks & Regards,
Lijo Thomas 

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: 23 November 2016 09:32
To: Lijo Thomas
Cc: [email-masked]
Subject: Re: [6lo] IETF 97 : Comments :
draft-lijo-6lo-expiration-time-00.txt

"Lijo Thomas" <[email-masked]> writes:
> the packet crosses over to network segments with different time zones. 
> For instance, when the packet traverses across  2 LBRs belonging to 
> different 6TiSCH networks due to different ASN time spaces. We plan to 
> discuss our resolution to such scenarios in our draft.

One general question which is not clear to me is whether this draft only
applies to 6tisch networks, or whether it applies to a broader class of
networks but is used in 6tisch networks slilghtly differently than in other
networks.  (I realize that this may be clear to everyone else from context,
but I am new to the WG.  But I think this point may trip up inexperienced
readers.)

 [LT] : The scope of the draft is more generic so that it can be used in any
time synchronized 6Lo network, not restricted to 6TiSCH alone. 6TiSCH is an
instantiation of such a time synchronized network, which has been used to
describe the implementation aspects of the draft in this scenario.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
-
What you say above is true, but the -00 version proposes to have the header
contain the expiration time, measured in microseconds after ASN=0, which has
the same difficulty -- if the packet is forwarded to a different zone, the
expiration time must be recalculated and stated relative to a different
epoch. 

 [LT] :Yes, it is very similar in spirit. The idea is to know the delay
accumulated by a packet in the network as it crosses different time zone
networks, origination time alone is not sufficient. The packet needs to
carry additional information apart from the origination time.

Here are our initial thoughts to address this space...

The "origination time" keeps track of the time at which the packet first
appears at the sub-network it is entering into. This time will be given with
respect to the time zone of that sub-net. An intermediate node can easily
compute the delay experienced by the packet within this sub-net. Along with
the origination time we need one more field  "segment delay" which keeps
track of the total delay already experienced before entering this sub-net.
The additive segment delay field gets added as the packet traverses along
sub-nets. These two time fields help us to determine the delay experienced
at each node at any point of time.

Your comments on this will be highly appreciated !!!!!!!
----------------------------------------------------------------------------
---------------------------
 And -00 describes these recalculations in the example Case 3 in section 5.
Or at least, Case 3 describes a version of these calculations, as that text
seems to assume that the header contains a count of time until expiration,
not the expiration time relative to an epoch.

 [LT] :  I would say the Case 3 in section 5 is actually a combination of
Case 1 and Case 2. Once the packet reaches LBR1, it applies the same rule as
described in Case 2 while routing the packet to LBR2 over a time
synchronized, likely wired backhaul.  The wired side of LBR2 can be mapped
to receiver of Case 2. Once the packet reaches LBR2 it applies the usual set
of time zone operations before pushing it down to DODAG2

The motivation for keeping Case 3, as a separate case is that we cover the
complete packet flow end-to-end; outbound from one 6Lo sub-net, and
re-entering into a different 6Lo sub-net via another time synchronized
network.

We feel Case 3 has not been described properly in our draft, and we will
update the text.
----------------------------------------------------------------------------
------------------------------------------------------------------
Though I believe that there is a lack of clarity in section 4 related to the
fact that the header contains an expiration time relative to an epoch.  The
header is named "Timestamp", which is a term usually used to describe
time-of-origin.  An alternative would be "Expiration", but that word often
means that the packet MUST be dropped at the indicated time.
A word I like is "Deadline", which implies that the network is required to
deliver the packet by the indicated time.

[LT] :  Nice suggestion :-) We will rename the header as "Deadline-6LoRH"
 
----------------------------------------------------------------------------
----------------------------------------------------------------
The last two sentences of the first paragraph in section 4 are

This is correct, but not fundamentally important, since origination time is
not carried in the header.  I wonder if you meant to say

or maybe better

[LT] :  We will do the editorial changes
----------------------------------------------------------------------------
-------------------------------------------------------
The following text in section 4 is correct but seems to me to not emphasize
the correct aspects of the situation

The length of the expiration time field is more affected by the ASN than by
the max_allowable_delay.  More realistic is to say

[LT] :  We will update the draft.
----------------------------------------------------------------------------
----------------------
Section 4 describes the header as an elective 6LoRH header.  As such, the
IANA Considerations should allocate a 6LoRH Type from the Elective 6LoWPAN
Routing Header Type registry (draft-ietf-roll-routing-dispatch-05, section
10.1), not the 6LoWPAN Dispatch Page1 number space as stated in section 6.

[LT] :  We will modify the draft so as to refer the IANA with Section 10.1.
----------------------------------------------------------------------------
--------------------------
In section 3, the description of the TSE field (bits 3 to 7 of the first
byte) does not agree with the description in
draft-ietf-roll-routing-dispatch-05, which specifies that these bits must be
the length of the header.  Technologically, the length of the expiration
time header must be encoded in a way independent of the header type, as the
header is elective and nodes that do not understand it must be able to
ignore it.

[LT] : Yes we intend to change the header to Critical header  from elective
header. We got the same comment from Pascal Thubert during the IETF 97
presentation.
----------------------------------------------------------------------------
--------------------------------------
In section 1, "RPI" is used in one place where "RPL" seems to be intended.

[LT] : Nops, we intend to use RPI only. But we will modify the draft
something like "RPL packet Information field as described in RFC 6553"..
----------------------------------------------------------------------------
---------------
Dale
Dale

_______________________________________________
6lo mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/6lo

---

From: "Lijo Thomas" <[email-masked]>
Date: Fri, 25 Nov 2016 10:47:07 +0530

Hi Dale,

Thanks for your valuable suggestion !!!

The explanation is perfect for the packets whose Source and Destination are
within the same network(For example., same 6TiSCH network).When a packet
traverses from heterogeneous networks then "Time in microseconds" is the
natural way to represent it.

We can think of designing "slot time" approach from Leaf node to LBR and
convert it into "Time(micro-seconds)" at the gateway node. But, again the
issue is we will be having Time mismatch during the conversion from
slot-time to "microseconds".

We will certainly work on the idea you suggested so that we can come up with
a proposition without compromising on the generality.

Thanks & Regards,
Lijo Thomas 

-----Original Message-----
From: 6lo [mailto:[email-masked]] On Behalf Of Dale R. Worley
Sent: 24 November 2016 09:23
To: [email-masked]; [email-masked]
Subject: Re: [6lo] IETF 97 : Comments :

To me, it would be natural to specify an expiration time as the
time-to-expiration, measured in slot times.
draft-lijo-6lo-expiration-time-00 specifies expiration time as an absolute
time, measured from ASN=0 in microseconds.  The latter approach seems to
require larger headers, without making processing much simpler.

It seems to me that measuring expriation time in microseconds is no more
useful than measuring it in slot times, because there is no functional
difference between any of the 10,000 microseconds within a single 10 ms slot
time.  But counting microseconds requires an additional 13 bits (over 1.5
octets) in the header.

Specifying time-to-expiration means that every time the packet is forwarded,
the expiration header must be updated.  But it can make the expiration
header shorter.  For instance, in the example I mentioned in my previous
message,

or

Dale

---

From: sajjad akbar <[email-masked]>
Date: Sat, 26 Nov 2016 12:34:35 +0000

Hi

Can anyone recommend me a draft where routing issues are discussed in 6lo?
I am working on link metrics for routing in low-power networks and it will
help me to align my research according to some standard.

Looking forward for the reply

Regards
Sajjad

On Fri, Nov 25, 2016 at 5:17 AM, Lijo Thomas <[email-masked]> wrote:

> slot
> forwarded,
> ------------------------------------------------------------
> -------------------------------------------------------------------
> ------------------------------------------------------------
> -------------------------------------------------------------------
>

---

From: sajjad akbar <[email-masked]>
Date: Tue, 29 Nov 2016 15:06:09 +0000

Hi Lijo

I joined the recommended group of routing, however I am looking for
multi-hop communication scenarios for these low-power devices which can be
connected to IPv6 network later. Can you suggest me something for this?

Kind Regards
Sajjad

On Mon, Nov 28, 2016 at 4:12 AM, Lijo Thomas <[email-masked]> wrote:

> Hi sajjad,
>
>
>
> Routing issues are discussed in roll  WG I guess.
>
>
>
> The compression of routing header is done by 6loRH and that is being
> discussed 6lo WG
>
>
>
> Please check the IETF main page to see the different WGs.
>
>
>
> If you can specify the exact solution looking for, maybe I would suggest
> if available.
>
>
>
>
>
>
>
> *Thanks & Regards,*
>
> *Lijo Thomas *
>
>
>
>
>
> *From:* sajjad akbar [mailto:[email-masked]]
> *Sent:* 26 November 2016 18:05
> *To:* Lijo Thomas
> *Cc:* Dale R. Worley; lo
>
> *Subject:* Re: [6lo] IETF 97 : Comments : draft-lijo-6lo-expiration-
> time-00.txt
>
>
>
> Hi
>
>
>
> Can anyone recommend me a draft where routing issues are discussed in
> 6lo?  I am working on link metrics for routing in low-power networks and it
> will help me to align my research according to some standard.
>
>
>