Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)

Charlie Perkins <> Sat, 27 July 2019 14:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0CA16120308; Sat, 27 Jul 2019 07:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key); domainkeys=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7XMCFvLb9awS; Sat, 27 Jul 2019 07:38:46 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5FC1D1202EA; Sat, 27 Jul 2019 07:38:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dk12062016; t=1564238326; bh=OMM3ZIXBPENiKBVCC4X++ZIS4ZOeK7oyvCZt 5rPU6fo=; h=Received:Subject:To:Cc:References:From:Message-ID:Date: User-Agent:MIME-Version:In-Reply-To:Content-Type: Content-Transfer-Encoding:Content-Language:X-ELNK-Trace: X-Originating-IP; b=kt97fGxYkxzEPu8077IyoHsH2F4mlioMXP6U7o12FbRzEQ trhfraYgUT/3bdHw1ID4ZuxNzckUOG5JPljt/fA56sWMoMi2GnARI/zGREoU9ol5D+h 370svY3Bd7cO1FGGzPru3WwBNVPFsUYaJtAaYfTeEeP58heKsBB6pN/Tn6XQHTvuUfd 5KE7cPC8xyKiev+qLotJytFTwKv6au5eoSsZdY3ZbvEcPa4Ccf2zTAWun+sdOzLwOG0 53uPtp9rFLmy1GNUsPwNX2viSV9R/lFKnfdtdw1+unEOU1xmlv/+zhWYmWbQNOw1kF2 ct9/b7ZrrVU8GtnkIIZqmRI0gk/Q==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016;; b=ZSmAXPA/S+HPKlD8oEBMOqiOzF/tbUngEP1X8A8g+GBT/O1HAnjEYczu5wZJyHyZkBw9EUfv446Dy7Whc/I+KhcHFmo5wcx+7faeO+CWdJOJEexdCA1Oi65fRrixKlgKeaOSfYpP3tSu+oNjYw8zycknyLfVOmalAuB/VERVlGoswMgHQRQLPIw1Lxw0rnyamy+H0q4dDkq3kl3KilFYrcrkZ3rvIbOBLCQBZZVg+pPNeeeqI3FrJZb2vAlqSa/vWgOmrf2BAJLxONsOc2x+AKkE5H/VD7yEX4LkkVNT8F9Rr98WkcWTbN5DPP8NljhMYFJA54vNkLKdVHU1456g0g==; h=Received:Subject:To:Cc:References:From:Message-ID:Date:User-Agent:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Content-Language:X-ELNK-Trace:X-Originating-IP;
Received: from [] (helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from <>) id 1hrNqP-000FGm-7a; Sat, 27 Jul 2019 10:38:45 -0400
To: Alissa Cooper <>, The IESG <>
Cc:, Samita Chakrabarti <>, Shwetha Bhandari <>,,
References: <>
From: Charlie Perkins <>
Message-ID: <>
Date: Sat, 27 Jul 2019 07:38:42 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c953353fafa955b5df0c224b3a5969765c8350badd9bab72f9c350badd9bab72f9c
Archived-At: <>
Subject: Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Mailing list for the 6lo WG for Internet Area issues in IPv6 over constrained node networks." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 27 Jul 2019 14:38:55 -0000

Hello folks,

The specification for handling wraparound has been significantly 
rewritten and clarified in the most recent revision of the document, 
draft-ietf-6lo-deadline-time-05.  I believe that the new text should 
resolve the questions raised in the Gen-ART review, and thus should 
resolve the issue mentioned by Alissa Cooper in her Discuss position.

The new text specifies how the value for the Deadline Time and 
Origination Time "fits" on the timelines of the sender and the receiver 
of the packet containing the Deadline-6LoRHE.  These timelines are 
synchronized so that both sender and receiver agree on the meanings of 
t0 and other time values on their timelines. Contrary to the earlier 
revision of the document, we do not assume that the synchronized 
timelines wrap around.  And, as noted, timelines demarcated by ASNs do 
NOT provide for wraparound.

To identify a particular Deadline Time on the synchronized timelines, 
the specification allows for using fewer bits than are needed for the 
full representation of the Deadline Time.  This works by effectively 
breaking up the synchronized timelines into subintervals, each 
containing a number of time units that is a power of 2.  So, for 
instance, if the length of the DT field is 8 bits, each subinterval of 
the synchronized timelines would contain 256 time units.  And, for this 
choice of subinterval length, the difference between the Origination 
Time and the Deadline Time could not exceed 255 time units.

As an example, suppose the Origination Time is ASN == 1050 and the 
Deadline Time == 1080.  These values can be carried in the 
Deadline-6LoRHE using only 8 bits for the Deadline Time.  The 
Origination Time is identified as a negative delta of 30 ASNs from the 
Deadline Time.  Since 1080 == 56 mod 256, the 8-bit value representing 
the Deadline Time (DT) would be 56.   And the Origination Time Delta 
(OTD) would be 30.

If, instead, the Origination Time occurred at ASN 1010 and the Deadline 
Time was 1040, then it is still possible to use only 8 bits for the 
Deadline time, and the Origination Time Delta (OTD) is still 30.   The 
Deadline-6LoRHE would carry the value 16 in the Deadline Time field.   
These examples are very similar, except that the Origination Time now 
lies in the subinterval that precedes the subinterval containing the 
Deadline Time.

In general, the size of the DT field has to be big enough to express the 
difference between the Origination Time and the Deadline Time.  
Otherwise, the value of the DT would be ambiguous at the receiver.  This 
is true even if the Deadline-6LoRHE does not include a value for the 
Origination Time Delta (OTD).

For small values of Deadline Time as used in the above examples, there 
might not be much savings in the size of the Deadline-6LoRHE.  However, 
for 64-bit time units specified with NTP, the Deadline-6LoRHE can often 
be a lot smaller if fewer bits are needed to express the Deadline Time 
(and Origination Time using OTD).

It seems to me that the idea of using smaller subintervals to express 
the times is a natural and clear way to lay out the values in the 
packet.  My apologies for finding it necessary to use so many words to 
express the idea.  I hope it's clear, and thanks to all that review the 
new text.

Charlie P.

On 5/15/2019 12:59 PM, Alissa Cooper via Datatracker wrote:
> Alissa Cooper has entered the following ballot position for
> draft-ietf-6lo-deadline-time-04: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> The Gen-ART reviewer made the following observation, which I'd like to discuss:
> There is a serious problem with the last 5 paragraphs of section 8,
> "Synchronization Aspects":  they seem to assume that the time
> representation for the Deadline Time and Origination Time values will
> wrap around, that is, that the representation is the absolute value
> modulo the size of the field.  In addition, there is a lack of clarity
> how the new epoch point will be chosen after the value wraps around.
> This seems to contradict the earlier sections of the document which
> speak of the values as if they are always to be considered as absolute
> values on a time scale selected by the TU field, viz., either the NTP
> time scale (in seconds) or the network's ASN numbering.
> It's possible that four of these paragraphs are intended to only apply
> to the use of TU = 00, the NTP time scale, and perhaps that usage of
> the header is understood not to be completely specified yet.
> However, the final paragraph discusses TU = 10 (the ASN time scale),
> and claims that wrapping of the DT value is intended.  This is
> relevant to current implementations.
> Some sort of resolution of this is needed; as the document stands it
> is self-inconsistent.  One possible resolution would be to omit these
> paragraphs.
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Please respond to the rest of the Gen-ART review.