Re: [6lo] IETF 97 : Comments : draft-lijo-6lo-expiration-time-00.txt
worley@ariadne.com (Dale R. Worley) Wed, 23 November 2016 04:04 UTC
Return-Path: <worley@alum.mit.edu>
X-Original-To: 6lo@ietfa.amsl.com
Delivered-To: 6lo@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FAD9129438 for <6lo@ietfa.amsl.com>; Tue, 22 Nov 2016 20:04:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level:
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G3fI4xZBfvsM for <6lo@ietfa.amsl.com>; Tue, 22 Nov 2016 20:04:29 -0800 (PST)
Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 368D6129418 for <6lo@ietf.org>; Tue, 22 Nov 2016 20:04:29 -0800 (PST)
Received: from resomta-po-18v.sys.comcast.net ([96.114.154.242]) by resqmta-po-08v.sys.comcast.net with SMTP id 9OnBcGEg52dNj9OnMc8npJ; Wed, 23 Nov 2016 04:04:28 +0000
Received: from hobgoblin.ariadne.com ([72.25.27.200]) by resomta-po-18v.sys.comcast.net with SMTP id 9OlEcUWNLsHiW9OlHcOGuB; Wed, 23 Nov 2016 04:02:26 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id uAN42DoN025596; Tue, 22 Nov 2016 23:02:13 -0500
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id uAN42CYH025593; Tue, 22 Nov 2016 23:02:12 -0500
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: Lijo Thomas <lijo@cdac.in>
In-Reply-To: <004a01d2447c$61ace540$2506afc0$@cdac.in> (lijo@cdac.in)
Sender: worley@ariadne.com
Date: Tue, 22 Nov 2016 23:02:12 -0500
Message-ID: <87mvgqrghn.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfMN/dRsPO4wlnL1EsYBRBppiv3s4PA3lSRle2e1ueRACZQWFyBDLIKp7oZ5zuxY56QnM/06QJqL43Kfk2gDvQIbSkvnc/2AeOKzB3bN+PqYl88+Ds72d uADXCR6fi2k3/RmOtAzYbh9JSyGZZ+9xYsN7vGoge+DwhxkemgTtHrjXp+18rS5lHKTwkULSIHuVfw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/zQAJnPP5jFwziwxEWShwSnFL0G8>
Cc: 6lo@ietf.org
Subject: Re: [6lo] IETF 97 : Comments : draft-lijo-6lo-expiration-time-00.txt
X-BeenThere: 6lo@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <6lo.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6lo>, <mailto:6lo-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6lo/>
List-Post: <mailto:6lo@ietf.org>
List-Help: <mailto:6lo-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6lo>, <mailto:6lo-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Nov 2016 04:04:30 -0000
"Lijo Thomas" <lijo@cdac.in> 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
- [6lo] IETF 97 : Comments : draft-lijo-6lo-expirat… Lijo Thomas
- [6lo] IETF 97 : Comments : draft-lijo-6lo-expirat… Lijo Thomas
- Re: [6lo] IETF 97 : Comments : draft-lijo-6lo-exp… Dale R. Worley
- Re: [6lo] IETF 97 : Comments : draft-lijo-6lo-exp… Dale R. Worley
- Re: [6lo] IETF 97 : Comments : draft-lijo-6lo-exp… Lijo Thomas
- Re: [6lo] IETF 97 : Comments : draft-lijo-6lo-exp… Lijo Thomas
- Re: [6lo] IETF 97 : Comments : draft-lijo-6lo-exp… sajjad akbar
- Re: [6lo] IETF 97 : Comments : draft-lijo-6lo-exp… sajjad akbar