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
