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 protected]] On Behalf Of Dale R. Worley Sent: 23 November 2016 09:32 To: Lijo Thomas Cc: [email protected] Subject: Re: [6lo] IETF 97 : Comments : draft-lijo-6lo-expiration-time-00.txt "Lijo Thomas" <[email protected]> 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 [email protected] 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. ------------------------------------------------------------------------------------------------------------------------------- _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
