Subject: [6lo] Alexey Melnikov's Discuss on draft-ietf-6lo-deadline-time-04: (with DISCUSS and COMMENT)

From: Alexey Melnikov via Datatracker <[email-masked]>
Date: Wed, 15 May 2019 05:59:50 -0700

Alexey Melnikov 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:
----------------------------------------------------------------------

I have a few small points (one is confusing enough to warrant a quick
discussion), but they affect clarity of the specification:

In Section 5:

   o  OTL (3 bits) : Length of OTD field as an unsigned 3-bit integer,
      encoding the length of the field in hex digits.  If OTL == 0, the
      OTD field is not present.  The value of OTL MUST NOT exceed the
      value of DTL plus one.

      *  For example, DTL = 0b0000 means the deadline time in the 6LoRHE
         is 1 hex digit (4 bits) long.

Ok, so 0b0000 ==> (0 + 1) * 4, means 4 bits.

          OTL = 0b111 means the
         origination time is 7 hex digits (28 bits) long.

Is my math wrong or is your example wrong?

0b111 == 7. So (7 + 1) * 4 would be 32 bits.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

In Section 4:

   There are multiple ways that a packet can be delayed, including
   queuing delay, MAC layer contention delay, serialization delay, and
   propagation delays.  Sometimes there are processing delays as well.
   For the purpose of determining whether or not the deadline has
   already passed, these various delays are not distinguished.

Not distinguished from what? Do you mean "not counted"?

In Section 5:

   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 would be good if you specified how negative values are represented (Ok,
maybe it is obvious) and the range for positive and negative values.

---

From: Barry Leiba <[email-masked]>
Date: Wed, 15 May 2019 09:22:21 -0400

This fits right into my comment about the +1 inviting confusion.  What

> Ok, so 0b0000 ==> (0 + 1) * 4, means 4 bits.

Correct.

> 0b111 == 7. So (7 + 1) * 4 would be 32 bits.

No, for OTL it's 7*4 = 28.

I do think this is unnecessarily confusing, and don't see why there's
a need for the +1 on the DTL.  (Yes, I read Carsten's comment in
response, but I don't find it compelling.)

It means that they are all delays, and the cause of the delay doesn't
matter -- there's no distinction among the different delays.

Barry