Re: [6lo] [Gen-art] Genart telechat review of draft-ietf-6lo-deadline-time-04
Alissa Cooper <alissa@cooperw.in> Wed, 15 May 2019 20:00 UTC
Return-Path: <alissa@cooperw.in>
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 C6CA0120236; Wed, 15 May 2019 13:00:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=V9OJ/e4r; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gHrF1XX4
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 MubllSQrAREL; Wed, 15 May 2019 13:00:24 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826F8120073; Wed, 15 May 2019 13:00:24 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id C3553408; Wed, 15 May 2019 16:00:22 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Wed, 15 May 2019 16:00:23 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=y J+lpiL2azfgYavlhBAp1vSgTbBl1nM8Q5TXA0lCBlw=; b=V9OJ/e4rUmZ7fG+yD vyZMNzqApmKHMGpMYAVUI7eQ4fufVhhWpUNftMjr9UP9EL+0F+wStzc2BAxepX1h rza3hzz+iNq+WWV4vS/2Qnrs25z72PbFvAiJLIBB3iYkCyvkxSw47WgpV+KbZI/p jL8HcdhrRhHWqefJupwJxyC2/iUOR9xUhweUk/N/uuIN27AjkfFzjyURKZPs2qX/ g56yLs9LgkA2nyACEy1WhkH+0JaIXxMXWq5z+d6HqRja3fYjdpLlGpGtHUkdCIi7 HGg+pwCUHONeCbKjkG7Uh9VzWnX2Om+2dHt3oQn2OMQ5VQ+svTpaJ0RZNpZaoyh4 U+r2A==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=yJ+lpiL2azfgYavlhBAp1vSgTbBl1nM8Q5TXA0lCB lw=; b=gHrF1XX4vHk3sW+7yycr3wXM/934hthm/2LGvmre2+YG2mqch1Qh7qphA 1sC8lZgCTlirlvVmHrXS4dOnay2UD/YlUOk8WlZTatd1sIWfqLT6oVDyoTwxcT3R DvIULqHxxl1o8VMzoDaMWFGUbOZqUskYBdYlwqokrjJPnW0SFgHZSpV9I3JobbBq d+RRKPV+7/a/cb33DNLXyjaifTUYOEPjwhrZJEYgWiQ8R2P38/0rKi7JPL7/RErk fRfNtJHoqZLwWqinv8oPpepY4TQPffW5QVpZPmIwjsgQzrIOnlLKM1LszintES7G I6BxqCGsJON60r7dRnn1SUqIx3NMA==
X-ME-Sender: <xms:1W_cXDn2Gsjol8eaGTvd-7FpCaMTM6J5kLs61JCXVGLCs8ODVu1CKQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrleekgddufeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinhepihgvthhfrdhorhhgnecukfhppedujeefrdefkedruddujedrkeelnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvghrfidrihhnnecuvehluhhsth gvrhfuihiivgeptd
X-ME-Proxy: <xmx:1m_cXIdrTRtB2G4l5dYCOCyDvC8JvavPduoE6uj5IFLu42p1kqTbUQ> <xmx:1m_cXIW89wRfPpSw28Rt-oAMk6Z_C7ZLlM4mOOVsbpurHPoEJ3KTqw> <xmx:1m_cXEEabokUSIROpipqqiqBLQPbTEx7xagjiVRFj_0Jwh8rV-eROA> <xmx:1m_cXAyhqexQkW2rSQjpSkUf7IjwKaHck2xNn-Su5pkXtf7NHltidw>
Received: from rtp-alcoop-nitro5.cisco.com (unknown [173.38.117.89]) by mail.messagingengine.com (Postfix) with ESMTPA id 6810180062; Wed, 15 May 2019 16:00:21 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <155710927530.5143.6871357856219241631@ietfa.amsl.com>
Date: Wed, 15 May 2019 16:00:19 -0400
Cc: gen-art@ietf.org, draft-ietf-6lo-deadline-time.all@ietf.org, ietf@ietf.org, 6lo@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <487F722F-B3A1-417C-9127-FAABCCD83EFA@cooperw.in>
References: <155710927530.5143.6871357856219241631@ietfa.amsl.com>
To: Dale Worley <worley@ariadne.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/6lo/kTIMfXdgfUDVMpTl_OsAOwsT9Lc>
Subject: Re: [6lo] [Gen-art] Genart telechat review of draft-ietf-6lo-deadline-time-04
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: Wed, 15 May 2019 20:00:29 -0000
Dale, thanks for your review. I entered a DISCUSS ballot to sort out the issue you raised about Section 8. Alissa > On May 5, 2019, at 10:21 PM, Dale Worley via Datatracker <noreply@ietf.org> wrote: > > Reviewer: Dale Worley > Review result: Ready with Issues > > I am the assigned Gen-ART reviewer for this draft. The General Area > Review Team (Gen-ART) reviews all IETF documents being processed > by the IESG for the IETF Chair. Please wait for direction from your > document shepherd or AD before posting a new version of the draft. > > For more information, please see the FAQ at > > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>. > > Document: draft-ietf-6lo-deadline-time-04 > Reviewer: Dale R. Worley > Review Date: 2019-05-05 > IETF LC End Date: 2018-12-24 > IESG Telechat date: 2019-05-16 > > Summary: > > This draft is on the right track but has open issues, described > in the review. > > There are a number of comments about the exposition that are listed > below. I'm sure these can be resolved by the authors. But 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. > > Nits/editorial comments: > > 3. 6LoRHE Generic Format > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ > |1|0|1| Length | Type | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ > <-- length --> > > Figure 1: 6LoRHE format > > o Length: Length of the 6LoRHE expressed in bytes, excluding the > first 2 bytes. This enables a node to skip a 6LoRHE if the Type > is not recognized/supported. > > o Type (variable length): Type of the 6LoRHE (see Section 7) > > There is a detail of this description which I don't like, and the > problem seems to be inherited from draft-ietf-roll-routing-dispatch, > viz., there is a variable-length field in the 6LoRHE, but it's not > named or described as such in that figure. The correct way to > describe the header is: > > 0 1 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ > |1|0|1| Length | Type | ... data ... | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ... -+ > <-- length --> > > Figure 1: 6LoRHE format > > o Length: Length of the 6LoRHE expressed in bytes, excluding the > first 2 bytes. This enables a node to skip a 6LoRHE if the Type > is not recognized/supported. > > o Type: Type of the 6LoRHE (see Section 7) > > o Data (Length bytes): Additional data. > > -- > > 4. Deadline-6LoRHE > > Since the OTD is a delta the > length of the OTD field (i.e., OTL) will require fewer bits than the > length of the DT field (i.e., DTL). > > Strictly speaking, it will usually require fewer bits. OTOH, it will > often require far fewer bits. Also, given the placement of "(i.e., > OTL)" there is an awkwardness regarding whether "OTL" is an > abbreviation for "the length of the OTD field" or an abbreviation for > "the OTD field". Conveniently, even a difference of 1 in the length > fields is significant, since they are in units of 4 bits. So perhaps > a better wording is: > > Since the OTD is a delta, the length (i.e., OTL) of the OTD field > will often be less than the length (i.e., DTL) of the DT field. > > -- > > 5. Deadline-6LoRHE Format > > o TU (2 bits) : Indicates the time units for DT and OTD fields. The > encoding for the DT and OTD fields MUST always use the same time > units and precision. > > * 00 : Time represented in seconds and fractional seconds > * 01 : Reserved > * 10 : Network ASN > * 11 : Reserved > > I think these could be made more explicit: > > o TU (2 bits) : Indicates the time unit and zero point for DT and > OTD fields. The encoding for the DT and OTD fields MUST always > use the same time units and precision. > > * 00 : Time represented in seconds and fractional seconds, > with 0 being the epoch of the NTP time scale, > 00:00:00 1 January 1900 UTC [RFC5905]. > * 01 : Reserved > * 10 : Network ASN > * 11 : Reserved > > Although there should be a warning that the NTP time scale has a > discontinuity whenever there is a leap second, so further > specification will be needed before the NTP time scale can be used in > delay-critical networks. > > -- > > o Binary Pt (6 bits) : If zero, the number of bits of the integer > part the DT is equal to the number of bits of the fractional part > of the DT. if nonzero, the Binary Pt is a signed integer > determining the position of the binary point within the value for > the DT. > > * If BinaryPt value is positive, then the number of bits for the > integer part of the DT is increased by the value of BinaryPt, > and the number of bits for the fractional part of the DT is > correspondingly reduced. This increases the range of DT. > * If BinaryPt value is negative, then the number of bits for the > integer part of the DT is decreased by the value of BinaryPt, > and the number of bits for the fractional part of the DT is > correspondingly increased. This increases the precision of the > fractional seconds part of DT. > > It seems like this could be stated much more succinctly. Also, the > signed integer format for Binary Pt needs to be specified. E.g., > > o Binary Pt (6 bits): A signed, twos-complement integer giving > the placement of the binary point in the DT field: > the number of integral bits is 2*(DTL+1) + BinaryPt > the number of fractional bits is 2*(DTL+1) - BinaryPt > > -- > > The scaling of the OTD value should be made explicit, as I see it as > an opportunity for errors: > > o OTD Value (8..64-bit) : An unsigned integer of OTL hex digits > giving the Origination Time as a negative offset from the DT value. > The rightmost bit of OTD has the same units as the rightmost bit > of DT. > > Then again, it's possible that the working group intended a different > scaling rule for OTD. > > For completeness, there should be a statement that if OTL+DTL is even, > then there will be a one-hex digit pad at the end of the value. > > 8. Synchronization Aspects > > The document supports time representation of the deadline and > origination times carried in the packets traversing through networks > of different time zones having different time synchronization > mechanisms. For instance, in a 6TiSCH network where the time is > maintained as ASN time slots, the time synchronization is achieved > through beaconing among the nodes as described in [RFC7554]. There > could be 6lo networks that employ NTP where the nodes are > synchronized with an external reference clock from an NTP server. > The specification of the time synchronization method that need to be > followed by a network is beyond the scope of the document. > > The number of hex digits chosen to represent DT, and the portion of > that field allocated to represent integer number of seconds, > determines the meaning of t_0, i.e., the meaning of DT == 0 in the > chosen representation. > > It's not clear to me why "the portion of that field allocated to > represent integer number of seconds" affects the meaning of the zero > DT value. Doesn't DT == 0 always represent the zero point of the time > scale selected by TU, regardless of the value of BinaryPt? > > If DTL == 0, then there are only 4 bits that > can be used to count the time units, so that DT == 0 can never be > more than 16 time units in the past. This then requires that the > time synchronization between sender and receiver has to be tighter > than 16 time units. If the binary point were moved so that all the > bits were used for fractional time units (e.g., fractional seconds or > fractional ASNs), the time synchronization requirement would be > correspondingly tighter. > > This paragraph is unclear to me. Presumably, the network will be > running for a long time (many time units) so the DT values will get > quite large. I suspect that the first sentence was to start "If OTL > == 1 ..." and then OT can never be more than 16 time units in the > past. In practice, this means that time synchronization has to be > tighter than 16 time units, or receivers will start randomly receiving > packets with DT in the past or OT in the future. > > A 4-bit field for DT allows up to 16 hex digits, which is 64 bits. > That is enough to represent the NTP [RFC5905] 64-bit timestamp > format, which is more than enough for the purposes of establishing > deadline times. Unless the binary point is moved, this is enough to > represent time since year 1900. > > If the binary point is not moved, this format can represent time from > year 1900 to year 2036, which is less than the expected lifetime of > this protocol. But BinaryPt >= 1 allows representing time until year > 2172, which should be adequate. > > For example, suppose that DTL = 0b0000 and the DT bits are split > evenly; then we can count up to 3 integer seconds. In that case t_0 > would be the most recent second of the current minute that has > t mod 4 == 0. In other words, t_0 could be 0, 4, 8, 12, 16, ..., 52, > or 56 seconds since the start of the most recent minute. The > networks have to be synchronized well enough to ensure detection of > overrun, and therefore to know which of those values is the correct > value for t_0. This is the hardest case. > > If DT = 3 and the DT bits are again split evenly, then we can count > up to 4,096 seconds. t_0 would be the start of the most recent hour. > > Where does this come from? I see no specification of DT containing > (deadline_time mod 2^(number of bits)). If a certain number of hex > digits is not large enough to express the time since the zero point of > the chosen time scale, DTL needs to be increased. > > Also, it's entirely unclear why, if truncating the high-order bits of > DT was defined, the beginning of each minute or hour would be chosen > as zero points. > > For TU = 0b00, the time units are seconds. With DTL == 15, and > Binary Pt == 0, the epoch is (by default) January 1, 1900 at 00:00 > UTC. The resolution is then (2 ^ (- 32)) seconds, which is the > maximum possible. > > BinaryPt can represent -32, which with DTL == 15, allows a resolution > of 2^-64 seconds (albeit for only 1 second after the zero point). > > This time format wraps around every 2^32 seconds, > which is roughly 136 years. > > There being no provision for time values wrapping around, the only > solution would be to move the binary point to the right. > > For other choices of DTL and the Binary > Pt, the value of t_0 (i.e., the meaning of DT == 0) needs to be > established by means out of scope of this document. > > For TU = 0b10, the time units are ASNs. The start time is relative, > and updated by a mechanism out of scope for this document. With 10 > ms slots, DTL = 15, and Binary Pt == 0, it would take over a year for > the ASN to wrap around. Typically, the number of hex digits > allocated for TU = 0b10 would be less than 15. > > [END] > > > _______________________________________________ > Gen-art mailing list > Gen-art@ietf.org > https://www.ietf.org/mailman/listinfo/gen-art
- [6lo] Genart telechat review of draft-ietf-6lo-de… Dale Worley via Datatracker
- Re: [6lo] [Gen-art] Genart telechat review of dra… Alissa Cooper