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

From: Charlie Perkins <[email-masked]>
Date: Fri, 8 Feb 2019 21:59:19 -0800

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

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 14 Feb 2019 21:37:31 -0500

> like to avoid restricting the use of the Deadline-6LoRHE to only 6TiSCH.

I agree that one could imagine any number of schemes, and in the long
run, broad use of Deadline-6LoRHE is desirable.  But that doesn't change
the fact that while the draft purports to define the meaning of three
values of the TU field, for two of those values, the draft doesn't
specify what zero-point is being used for the time scale, and so
implementations using those values cannot ensure interoperation.

Now if what you really mean is "NTP time scale in microseconds" and "NTP
time scale in seconds", those *are* definitions.  But that's not what the
draft says.

> soon.  I agree that, if both values are present, one should be a delta 

The way you write that suggests that either or both of the times can be
present.  But the deadline time is not optional.  So if the origination
time is present, both times are present.

Dale

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 16 Feb 2019 14:39:55 -0800

Hello Dale,

I made some brief follow-up to your comments inline below.  I think we 
are in agreement about what needs to be done.

> time scale in seconds", those *are* definitions.  But that's not what the

We have revamped the way of representing the deadline time and optional 
origination time, and I think it will resolve your comments here.  In a 
nutshell, we are following the recommendations in 
draft-ietf-ntp-packet-timestamps.

> ...

Agreed, and the new revision will make this clear as well.

Regards,
Charlie P.