Subject: [Gen-art] Genart telechat review of draft-ietf-6lo-deadline-time-04

From: Dale Worley via Datatracker <[email-masked]>
Date: Sun, 05 May 2019 19:21:15 -0700

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]

---

From: Alissa Cooper <[email-masked]>
Date: Wed, 15 May 2019 16:00:19 -0400

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 <[email-masked]> wrote:
> 
> Reviewer: Dale Worley
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art