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

["Lijo Thomas" <[e-mail]>]

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:[e-mail]] On Behalf Of Dale R. Worley
Sent: 23 November 2016 09:32
To: Lijo Thomas
Cc: [e-mail]
Subject: Re: [6lo] IETF 97 : Comments :
draft-lijo-6lo-expiration-time-00.txt

"Lijo Thomas" <[e-mail]> 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.)

 [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

   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.

[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

   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.

[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
[e-mail]
https://www.ietf.org/mailman/listinfo/6lo


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