Last Call Review of draft-ietf-6lo-deadline-time-03
review-ietf-6lo-deadline-time-03-genart-lc-worley-2018-12-22-00

Request Review of draft-ietf-6lo-deadline-time
Requested rev. no specific revision (document currently at 05)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-12-24
Requested 2018-12-10
Authors Lijo Thomas, Satish Anamalamudi, S.V.R Anand, Malati Hegde, Charles Perkins
Draft last updated 2018-12-22
Completed reviews Iotdir Early review of -02 by Wesley Eddy (diff)
Rtgdir Telechat review of -03 by Dan Frost (diff)
Secdir Last Call review of -03 by Charlie Kaufman (diff)
Genart Last Call review of -03 by Dale Worley (diff)
Genart Telechat review of -04 by Dale Worley (diff)
Secdir Telechat review of -04 by Charlie Kaufman (diff)
Assignment Reviewer Dale Worley
State Completed
Review review-ietf-6lo-deadline-time-03-genart-lc-worley-2018-12-22
Reviewed rev. 03 (document currently at 05)
Review result Ready with Issues
Review completed: 2018-12-22

Review
review-ietf-6lo-deadline-time-03-genart-lc-worley-2018-12-22

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document:  draft-ietf-6lo-deadline-time-03
Reviewer:  Dale R. Worley
Review Date:  
IETF LC End Date:  2018-12-24
IESG Telechat date:  unknown

Summary:

    This draft is on the right track but has open issues, described
    in the 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.

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.

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.

Nits/editorial comments: 

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]