Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
Charlie Perkins <charles.perkins@earthlink.net> Sat, 27 July 2019 14:38 UTC
Return-Path: <charles.perkins@earthlink.net>
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 0CA16120308; Sat, 27 Jul 2019 07:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=earthlink.net; domainkeys=pass (2048-bit key) header.from=charles.perkins@earthlink.net header.d=earthlink.net
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 7XMCFvLb9awS; Sat, 27 Jul 2019 07:38:46 -0700 (PDT)
Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) (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 5FC1D1202EA; Sat, 27 Jul 2019 07:38:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=earthlink.net; 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; d=earthlink.net; 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 [99.51.72.196] (helo=[192.168.1.82]) by elasmtp-mealy.atl.sa.earthlink.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4) (envelope-from <charles.perkins@earthlink.net>) id 1hrNqP-000FGm-7a; Sat, 27 Jul 2019 10:38:45 -0400
To: Alissa Cooper <alissa@cooperw.in>, The IESG <iesg@ietf.org>
Cc: draft-ietf-6lo-deadline-time@ietf.org, Samita Chakrabarti <samitac.ietf@gmail.com>, Shwetha Bhandari <shwethab@cisco.com>, 6lo-chairs@ietf.org, 6lo@ietf.org
References: <155795036138.30487.11797662134705391956.idtracker@ietfa.amsl.com>
From: Charlie Perkins <charles.perkins@earthlink.net>
Message-ID: <683e3f76-56eb-fd29-3630-eb853994f68e@earthlink.net>
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: <155795036138.30487.11797662134705391956.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956846b590522b13c953353fafa955b5df0c224b3a5969765c8350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.51.72.196
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/7-Cv57TlltqCZ5ukFhwPh_GTRpE>
Subject: Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)
X-BeenThere: 6lo@ietf.org
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." <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: 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. Regards, 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 https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ > > > > ---------------------------------------------------------------------- > DISCUSS: > ---------------------------------------------------------------------- > > 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. > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Please respond to the rest of the Gen-ART review. > > >
- [6lo] Alissa Cooper's Discuss on draft-ietf-6lo-d… Alissa Cooper via Datatracker
- Re: [6lo] Alissa Cooper's Discuss on draft-ietf-6… Charlie Perkins