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]
