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