Hi, Thanks you for the comments, please see below. On 3/20/2019 10:33 PM, Dale Worley via Datatracker wrote:
Reviewer: Dale Worley Review result: Ready with Nits 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-manet-dlep-pause-extension-05 Reviewer: Dale R. Worley Review Date: 2019-03-20 IETF LC End Date: 2019-04-03 IESG Telechat date: [not scheduled] Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. There are a number of issues with technical content, but they appear to stem from editorial issues, rather than being unsettled technical decisions. * Technical issues: I notice that the Pause Extension cannot be used by a router to tell a modem to not send. I assume that the WG has considered this and has a good reason for this asymmetry.
This is correct. It was deemed unneeded complexity for the typical use case where modems have very narrow bandwidth available for transmissions in comparison to other router attached links.
3.1.1. Queue Parameter Sub Data Item There need not be a Sub Data Item for a particular queue index. Such a queue has no declared size. OTOH, it has no DSCPs, and so no traffic can be sent for it, either. Queue Parameter Sub Data Items are an unordered list composed of sub data items with a common format. The first sub data item is assigned a Queue Index value of 1, and subsequent data items are numbered incrementally. The format of the Queue Parameter Sub Data Item is ... Queue Index: An 8-bit field indicating the queue index of the queue parameter represented in the sub data item. These passages are contradictory. Either the Sub Data Items are an ordered list and indexes are assigned to them sequentially, they are unordered and the indexes are given in the Queue Index subfield, or the Sub Data Items are required to be in order by their Queue Index fields.
Good catch - and you are correct. This is text wasn't modified when we made ordering explicit.
The following will be removed: The first sub data item is assigned a Queue Index value of 1, and subsequent data items are numbered incrementally.
DS Field Qn: The data item contains a sequence of 8 bit DS Fields. The position in the sequence identifies the associated queue index. The number of DS Fields present MUST equal the sum of all Num DSCPs field values. This doesn't seem to match the defined format of the Sub Data Items. The "DS Field Qn" fields contain exactly as many DS Fields as the value of the Num DSCPs Qn field by definition. And all of them are associated with the one Queue Index in the Sub Data Item containing the DS Field Qn.
Same issue. Drop: The position in the sequence identifies the associated queue index.
I note that the Sub Data Items are not padded to a multiple of 4 octets. I assume this is intended.
Correct, this is consistent with rfc8175.
3.3. Restart The sending of this data item parallels the Pause Data Item, see the previous section, and follows the same rules. This includes that to indicate that transmission can resume to all destinations, a modem MUST send the Restart Data Item in a Session Update Message. It also includes that to indicate that transmission can resume to a particular destination a modem MUST send the Pause Restart Item in a Destination Update Message. Read literally, this means that there is a pause/transmit bit for each destination/DSCP combination, and that the various messages (pause vs. restart * Session Update vs. Destination Update * queue index vs. 255) set some subset of the bits to "pause" or "transmit". This is opposed to the model where (to simplify) there is an overall pause/transmit bit for all traffic and an independent pause/transmit bit for each destination, and traffic may be sent for a destination only if both the overall bit and the destination bit are "transmit". * Editorial issues: 1. Introduction The extension also optionally supports DSCP (differentiated services codepoint) aware, see [RFC2475], flow control. The phrasing of this sentence is awkward because of the number of interpolated phrases. I suggest something like: The extension also optionally supports flow control that is DSCP (differentiated services codepoint) aware (see [RFC2475]).
I'll break it into two sentences.
Also, it seems that recent RFCs have tended to capitalize the phrase "Differentiated Services Code Point". (Probably check this point with the Editor.)
I'll defer to the RFC editor.
Note that this mechanism only controls traffic that is to be transmitted on the modem's attached data channel and not to DLEP control messages themselves. The parallelism is not correct here, as it would read "this mechanism ... controls ... to DLEP". Perhaps change to: "this mechanism only applies to traffic ...".
Thanks!
2. Extension Usage and Identification To indicate that the Control Plane Based Pause Extension is to be used, an implementation MUST include the Control Plane Based Pause Extension Type Value in the Extensions Supported Data Item. If I am reading RFC 8175 correctly, this is not exactly true. Sending the Value does not compel the peer device to use the Extension. Instead, "To indicate that the implementation accepts use of the C.P.B.P.E., an implementation includes ...".
thanks, but will s/accepts/supports.
3. Extension Data Items The Queue Parameters Data Item is used by a modem to provide information on the DSCPs it uses in forwarding. Suggest s/information on/information about/. To me, "information on the DSCPs" suggests that it will provide a listing of all the DSCPs that it uses, whereas "information about the DSCPs" suggests that it will provide attributes of some, but perhaps not all, of the DSCPs. (Section 3.1 makes clear that the Queue Parameters does not need to list all DSCPs that are used.)
Done!
3.1. Queue Parameters The Queue Parameters Data Item identifies DSCPs based on groups of logical queues, each of which is referred to via a "Queue Index". "groups of logical queues" isn't correct. Suggest "The Queue Parameters Data Item groups DSCPs into logical queues, each of which is identified by a "Queue Index"."
I like it - thanks!
An implementation that does not support DSCPs would indicate 1 queue with 0 DSCPs, and the number of bytes that may be in its associated link transmit queue. "with 0 DSCPs" is not really correct, since the Queue Parameter doesn't specify how many DSCPs are included in queue index 0, and traffic with all values of the DSCP field (which is unexamined by the device) will be in queue index 0. I think this phrase should be omitted.
I think it's cleaner to remove Q0 at this point, it too is a bit vestigial and I think this highlights that having essentially two ways to cover the
Value Scale ------------ 0 B - Bytes (Octets) 1 KB - Kilobytes (B/1024) 2 MB - Megabytes (KB/1024) 3 GB - Gigabytes (MB/1024) I would expect these items to be "1024 B", "1024 KB", etc. But perhaps that's because it is ambiguous whether "scale" means the units in which the measurement is expressed, or the factor by which the measurement is multiplied by before it is reported. I would replace "scale" with "unit", which does not have that ambiguity. I would also use the IEC abbreviations: Value Unit ----------- 0 B - Bytes (Octets) 1 KiB - Kilobytes (1024 B) 2 MiB - Megabytes (1024 KiB) 3 GiB - Gigabytes (1024 GiB)
Sure.
[ISQ-13] International Electrotechnical Commission, "International Standard -- Quantities and units -- Part 13: Information science and technology", IEC 80000-13, March 2008. 3.2. Pause The special value of 255 is used to indicate that all traffic is to be suppressed. This implies that a queue index of 255 cannot be used, which is also implied by the fact that Num Queues = 255 means that only indexes 0 to 254 are in use. It would be helpful to update 3.1 to make this more explicit: Queue Indexes are numbered sequentially from zero to a maximum of 254, where queue index zero is a special case covering DSCPs which are not otherwise associated with Queue Index. (Value 255 is used to indicate "all queues".)
I'll add text that 255 MUST NOT be used in the Queue Index field.
-- Queue Index: ... The special value of 255 indicates all traffic is to be suppressed to the modem, when the data item is carried in a Session Update Message, or a destination, when the data item is carried in Destination Update Message. The parallelism is awkward here. I think you want to explicitly parallel "traffic to the modem" and "traffic to a destination":
okay, will make them parallel.
The special value of 255 indicates all traffic to the modem is to be suppressed, when the data item is carried in a Session Update Message, or all traffic to a destination, when the data item is carried in Destination Update Message. 3.3. Restart Finally, the same rules apply to queue indexes. Probably better as "Queue indexes are interpreted in the same way as in the Pause Data Item."
Done. Look for an update to be published shortly. Thank you for the comments! Lou
[END]