Hello Dale,
I have incorporated resolutions to your comments in a new revision for
the deadling-time document. Please see a bit of follow-up below,
interspersed with your comments.
On 12/22/2018 7:35 PM, Dale Worley wrote:
Summary:
This draft is on the right track but has open issues, described
in the review.
Thank you very much for the detailed review.
Major issues:
1. In regard to the TU field of the header:
TU (2 bits) : Indicates the time units for DT and OT fields
00 : Time represented in microseconds
01 : Time represented in seconds
10 : Network ASN
11 : Reserved
Note that to define DT and OT, we need to specify not only a time
unit, but the instant of zero time. Network ASN has a zero time
defined by the network, but for the other two choices, the zero time
is not specified by this document. Perhaps it is intended that any
"time-synchronized network" necessarily defines a zero time and that
is being referenced here. If that is so, it should probably be made
explicit.
I put in the following clarification. I hope it will be sufficient to
resolve your observation.
The deadline time enables forwarding and scheduling
decisions for time critical IoT M2M applications that
operate within time-synchronized networks that agree on the
meaning of the time representations used for the deadline
time values.
As noted in responses to other reviewers, we are going to adopt time
representations that are derived from the formats presented in
draft-ietf-ntp-packet-timestamps-05.txt.
Indeed, it is probably worth going farther: The 10 value is only
meaningful in 6TiSCH networks. So really, the interpretation of TU is
scoped to the underlying network technology and the definition(s) of
time it provides. The defintion of TU in this document should be
something like this:
TU (2 bits) : Indicates the time scale for DT and OT fields
Values depend on the underlying network technology. For
6TiSCH networks:
00 : Reserved
01 : Reserved
10 : Network ASN
11 : Reserved
Values in other networks are out of scope of this document.
I'm not sure about this because even in 6TiSCH networks, one could
imagine using NTP-based time representations. Besides that, we'd really
like to avoid restricting the use of the Deadline-6LoRHE to only 6TiSCH.
2. I'm surprised that the OT value is represented as an absolute value
from the time-base used for the particular Deadline-6LoRHE, rather
than as an offset before the DT. The difference DT - OT will
typically be much smaller than OT itself, so if O = 1 and OT is
present, using a difference would usually shorten the header. This
change clearly isn't necessary for correctness, but it seems like a
significant efficiency gain, as after 1 year, a 10 msec ASN with have
values nearing 2^32, but DT - OT may remain less than 2^8.
We will rework the time representation and show a proposed new format
soon. I agree that, if both values are present, one should be a delta
from the other.
Nits/editorial comments:
All of the following editorial suggestions have been adopted into the
new revision. Thanks again!
Regards,
Charlie P.
Abstract
The deadline
time enables forwarding and scheduling decisions for time critical
IoT M2M applications that need deterministic delay guarantees over
constrained networks and operate within time-synchronized networks.
It's not clear to me how much "over constrained networks and operate
within time-synchronized networks" adds to this sentence. True, this
header requires that nodes have a common sense of time, but does that
require a "time-synchronized network"? (OTOH, perhaps that is what
"time-synchronized network" *means*, but I don't know that.)
And while 6LoWPAN is expected to be operated across a constrained
network, a constrained network isn't a requirement for its use. OTOH,
perhaps what you mean is that the header is designed for use over
constrained networks, i.e., it is bit-efficient. In that case, I'd
relocate the phrase to "... delivery deadline time for data packets,
designed for use over constrained networks."
1. Introduction
... compression schemes for RPL routing (source
routing) operation [RFC6554], ...
It might be helpful to define "RPL". I think better wording would be
"compression schemes for [RFC6554] RPL routing", or "compression
schemes for RPL routing using [RFC6554]".
The draft [I-D.ietf-roll-routing-dispatch] specifies the 6LoWPAN
Routing Header (6LoRH), compression schemes for RPL routing (source
routing) operation [RFC6554], header compression of RPL Packet
Information [RFC6553], and IP-in-IP encapsulation. This document
specifies a new Deadline-6LoRHE type for the 6LoWPAN Dispatch Page 1,
so that the deadline time of data packets can be included within the
6LoWPAN routing header.
I think these two sentences could be clarified along these lines:
This document specifies a new Deadline-6LoRHE type for the Elective
6LoWPAN Routing Header Type, so that the deadline time of data
packets can be included within the 6LoWPAN routing header. RFC
8138 [formerly ietf-roll-routing-dispatch] specifies the 6LoWPAN
Routing Header (6LoRH), compression schemes for RPL routing (source
routing) operation [RFC6554], header compression of RPL Packet
Information [RFC6553], and IP-in-IP encapsulation.
--
This document also specifies handling of the
deadline time when packets traverse through time-synchronized
networks operating in different timezones or distinct reference
clocks.
Perhaps s/traverse through/traverse between/.
Time synchronization techniques need not be mandated by this
specificiation.
"are not mandated" would be better -- "need not be mandated" sounds
like a (lack of) requirement for the document itself. Or use the
conventional "Time synchronization techniques are outside the scope of
this document."
A 6TiSCH network has been used to describe the implementation of the
Deadline-6LoRHE, but this does not preclude its use in scenarios
other than 6TiSCH.
Probably s/has been used/is used/.
BLE mesh time synchronization is also
being recently explored by the Bluetooth community.
s/is also being recently explored/is being explored/ -- "recently"
implies that the action has ended before the present.
2. Terminology
This document uses terminology consistent with the terminology used
in [RFC6550] and [I-D.ietf-6tisch-terminology].
I think you mean that it "uses the terminology defined in ..."; to say
it is "consistent with" can mean just that this document's terminology
does not conflict with that of other documents.
Also, in this
document, the terms "expiration time", "delivery deadline time", and
"deadline" are used interchangeably with the same meaning.
It's best to use only one term for a single concept.
3. 6LoRHE Generic Format
o Type: Type of the 6LoRHE.
You should add that this value is defined in section 7.
4. Deadline-6LoRHE
I think Figure 2 could be made more informative by making the transit
out on network TZ3 explicit and by realigning the blocks of values.
Note that I've shifted the diagram 3 spaces to the left to obtain room
for these changes.
TZ1 TZ2 TZ3
T1A=0| | |
|---- D1=100 | |
| \ | |
| \ | |
| \ T1D=100 |T2A=1000 |
| -------->|----- D2=400 |
| | \ |
| | \ |
| | \ T2D=1400 | T3A=5000
| | ------------------->|---------->
| | |
v v v
D = 0 D = T1D-OT D = T2D-OT
= 100-0 = 1400 - 900
= 100 = 500 [= (D1 + D2)]
OT = T1A-D OT = T2A-D OT = T3A-D
= 0 = 1000-100 = 5000 - 500
= 900 = 4500
5. Deadline-6LoRHE Format
6LoRH Type: TBD
This should have a reference to section 7.
6.1. Scenario 1: Endpoints in the same DODAG (N1)
Figure 5 could be made a bit clearer (and figures 6 and 7 modified
similarly):
+-------+
^ | 6LBR | |
| | | |
| +-------+ |
Upward | / /| \ | Downward
routing | (F) / | \ | routing
| / \ (C) | (D) |
| / \ | | / |\ |
| (A) (B) : (E) : R |
| /|\ | \ / \ |
| S : : : : : : v
[END]
