Re: [Gen-art] Genart last call review of draft-ietf-6lo-deadline-time-03

[Charlie Perkins <[e-mail]>]

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]
>
>
>