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 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
