Re: [Gen-art] Genart telechat review of draft-ietf-6lo-deadline-time-04

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Dale, thanks for your review. I entered a DISCUSS ballot to sort out the issue you raised about Section 8.

Alissa

> On May 5, 2019, at 10:21 PM, Dale Worley via Datatracker <noreply@xxxxxxxx> wrote:
> 
> Reviewer: Dale Worley
> Review result: Ready with Issues
> 
> 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 wait for direction from your
> document shepherd or AD before posting a new version of the draft.
> 
> For more information, please see the FAQ at
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document:  draft-ietf-6lo-deadline-time-04
> Reviewer:  Dale R. Worley
> Review Date:   2019-05-05
> IETF LC End Date:  2018-12-24
> IESG Telechat date:  2019-05-16
> 
> Summary:
> 
>       This draft is on the right track but has open issues, described
>       in the review.
> 
> There are a number of comments about the exposition that are listed
> below.  I'm sure these can be resolved by the authors.  But 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.
> 
> Nits/editorial comments:
> 
>   3.  6LoRHE Generic Format
> 
>      0                   1
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-             ...               -+
>     |1|0|1| Length  |      Type     |                                 |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-             ...               -+
>                                      <--          length           -->
> 
>                          Figure 1: 6LoRHE format
> 
>   o  Length: Length of the 6LoRHE expressed in bytes, excluding the
>      first 2 bytes.  This enables a node to skip a 6LoRHE if the Type
>      is not recognized/supported.
> 
>   o  Type (variable length): Type of the 6LoRHE (see Section 7)
> 
> There is a detail of this description which I don't like, and the
> problem seems to be inherited from draft-ietf-roll-routing-dispatch,
> viz., there is a variable-length field in the 6LoRHE, but it's not
> named or described as such in that figure.  The correct way to
> describe the header is:
> 
>      0                   1
>      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-             ...               -+
>     |1|0|1| Length  |      Type     |          ... data ...           |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-             ...               -+
>                                      <--          length           -->
> 
>                          Figure 1: 6LoRHE format
> 
>   o  Length: Length of the 6LoRHE expressed in bytes, excluding the
>      first 2 bytes.  This enables a node to skip a 6LoRHE if the Type
>      is not recognized/supported.
> 
>   o  Type: Type of the 6LoRHE (see Section 7)
> 
>   o  Data (Length bytes): Additional data.  
> 
> --
> 
>   4.  Deadline-6LoRHE
> 
>   Since the OTD is a delta the
>   length of the OTD field (i.e., OTL) will require fewer bits than the
>   length of the DT field (i.e., DTL).
> 
> Strictly speaking, it will usually require fewer bits.  OTOH, it will
> often require far fewer bits.  Also, given the placement of "(i.e.,
> OTL)" there is an awkwardness regarding whether "OTL" is an
> abbreviation for "the length of the OTD field" or an abbreviation for
> "the OTD field".  Conveniently, even a difference of 1 in the length
> fields is significant, since they are in units of 4 bits.  So perhaps
> a better wording is:
> 
>   Since the OTD is a delta, the length (i.e., OTL) of the OTD field
>   will often be less than the length (i.e., DTL) of the DT field.
> 
> --
> 
>   5.  Deadline-6LoRHE Format
> 
>   o  TU (2 bits) : Indicates the time units for DT and OTD fields.  The
>      encoding for the DT and OTD fields MUST always use the same time
>      units and precision.
> 
>      *  00 : Time represented in seconds and fractional seconds
>      *  01 : Reserved
>      *  10 : Network ASN
>      *  11 : Reserved
> 
> I think these could be made more explicit:
> 
>   o  TU (2 bits) : Indicates the time unit and zero point for DT and
>      OTD fields.  The encoding for the DT and OTD fields MUST always
>      use the same time units and precision.
> 
>      *  00 : Time represented in seconds and fractional seconds,
>              with 0 being the epoch of the NTP time scale,
>              00:00:00 1 January 1900 UTC [RFC5905].
>      *  01 : Reserved
>      *  10 : Network ASN
>      *  11 : Reserved
> 
> Although there should be a warning that the NTP time scale has a
> discontinuity whenever there is a leap second, so further
> specification will be needed before the NTP time scale can be used in
> delay-critical networks.
> 
> --
> 
>   o  Binary Pt (6 bits) : If zero, the number of bits of the integer
>      part the DT is equal to the number of bits of the fractional part
>      of the DT.  if nonzero, the Binary Pt is a signed integer
>      determining the position of the binary point within the value for
>      the DT.
> 
>      *  If BinaryPt value is positive, then the number of bits for the
>         integer part of the DT is increased by the value of BinaryPt,
>         and the number of bits for the fractional part of the DT is
>         correspondingly reduced.  This increases the range of DT.
>      *  If BinaryPt value is negative, then the number of bits for the
>         integer part of the DT is decreased by the value of BinaryPt,
>         and the number of bits for the fractional part of the DT is
>         correspondingly increased.  This increases the precision of the
>         fractional seconds part of DT.
> 
> It seems like this could be stated much more succinctly.  Also, the
> signed integer format for Binary Pt needs to be specified.  E.g.,
> 
>   o  Binary Pt (6 bits):  A signed, twos-complement integer giving
>      the placement of the binary point in the DT field:  
>      the number of integral bits is 2*(DTL+1) + BinaryPt
>      the number of fractional bits is 2*(DTL+1) - BinaryPt
> 
> --
> 
> The scaling of the OTD value should be made explicit, as I see it as
> an opportunity for errors:
> 
>   o  OTD Value (8..64-bit) : An unsigned integer of OTL hex digits
>      giving the Origination Time as a negative offset from the DT value.
>      The rightmost bit of OTD has the same units as the rightmost bit
>      of DT.
> 
> Then again, it's possible that the working group intended a different
> scaling rule for OTD.
> 
> For completeness, there should be a statement that if OTL+DTL is even,
> then there will be a one-hex digit pad at the end of the value.
> 
>   8.  Synchronization Aspects
> 
>   The document supports time representation of the deadline and
>   origination times carried in the packets traversing through networks
>   of different time zones having different time synchronization
>   mechanisms.  For instance, in a 6TiSCH network where the time is
>   maintained as ASN time slots, the time synchronization is achieved
>   through beaconing among the nodes as described in [RFC7554].  There
>   could be 6lo networks that employ NTP where the nodes are
>   synchronized with an external reference clock from an NTP server.
>   The specification of the time synchronization method that need to be
>   followed by a network is beyond the scope of the document.
> 
>   The number of hex digits chosen to represent DT, and the portion of
>   that field allocated to represent integer number of seconds,
>   determines the meaning of t_0, i.e., the meaning of DT == 0 in the
>   chosen representation.
> 
> It's not clear to me why "the portion of that field allocated to
> represent integer number of seconds" affects the meaning of the zero
> DT value.  Doesn't DT == 0 always represent the zero point of the time
> scale selected by TU, regardless of the value of BinaryPt?
> 
>   If DTL == 0, then there are only 4 bits that
>   can be used to count the time units, so that DT == 0 can never be
>   more than 16 time units in the past.  This then requires that the
>   time synchronization between sender and receiver has to be tighter
>   than 16 time units.  If the binary point were moved so that all the
>   bits were used for fractional time units (e.g., fractional seconds or
>   fractional ASNs), the time synchronization requirement would be
>   correspondingly tighter.
> 
> This paragraph is unclear to me.  Presumably, the network will be
> running for a long time (many time units) so the DT values will get
> quite large.  I suspect that the first sentence was to start "If OTL
> == 1 ..." and then OT can never be more than 16 time units in the
> past.  In practice, this means that time synchronization has to be
> tighter than 16 time units, or receivers will start randomly receiving
> packets with DT in the past or OT in the future.
> 
>   A 4-bit field for DT allows up to 16 hex digits, which is 64 bits.
>   That is enough to represent the NTP [RFC5905] 64-bit timestamp
>   format, which is more than enough for the purposes of establishing
>   deadline times.  Unless the binary point is moved, this is enough to
>   represent time since year 1900.
> 
> If the binary point is not moved, this format can represent time from
> year 1900 to year 2036, which is less than the expected lifetime of
> this protocol.  But BinaryPt >= 1 allows representing time until year
> 2172, which should be adequate.
> 
>   For example, suppose that DTL = 0b0000 and the DT bits are split
>   evenly; then we can count up to 3 integer seconds.  In that case t_0
>   would be the most recent second of the current minute that has
>   t mod 4 == 0.  In other words, t_0 could be 0, 4, 8, 12, 16, ...., 52,
>   or 56 seconds since the start of the most recent minute.  The
>   networks have to be synchronized well enough to ensure detection of
>   overrun, and therefore to know which of those values is the correct
>   value for t_0.  This is the hardest case.
> 
>   If DT = 3 and the DT bits are again split evenly, then we can count
>   up to 4,096 seconds.  t_0 would be the start of the most recent hour.
> 
> Where does this come from?  I see no specification of DT containing
> (deadline_time mod 2^(number of bits)).  If a certain number of hex
> digits is not large enough to express the time since the zero point of
> the chosen time scale, DTL needs to be increased.
> 
> Also, it's entirely unclear why, if truncating the high-order bits of
> DT was defined, the beginning of each minute or hour would be chosen
> as zero points.
> 
>   For TU = 0b00, the time units are seconds.  With DTL == 15, and
>   Binary Pt == 0, the epoch is (by default) January 1, 1900 at 00:00
>   UTC.  The resolution is then (2 ^ (- 32)) seconds, which is the
>   maximum possible.
> 
> BinaryPt can represent -32, which with DTL == 15, allows a resolution
> of 2^-64 seconds (albeit for only 1 second after the zero point).
> 
>   This time format wraps around every 2^32 seconds,
>   which is roughly 136 years.
> 
> There being no provision for time values wrapping around, the only
> solution would be to move the binary point to the right.
> 
>   For other choices of DTL and the Binary
>   Pt, the value of t_0 (i.e., the meaning of DT == 0) needs to be
>   established by means out of scope of this document.
> 
>   For TU = 0b10, the time units are ASNs.  The start time is relative,
>   and updated by a mechanism out of scope for this document.  With 10
>   ms slots, DTL = 15, and Binary Pt == 0, it would take over a year for
>   the ASN to wrap around.  Typically, the number of hex digits
>   allocated for TU = 0b10 would be less than 15.
> 
> [END]
> 
> 
> _______________________________________________
> Gen-art mailing list
> Gen-art@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/gen-art





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux