Robert, Thanks for the review. > At the end of page 13, the sentence that starts "Transport protocol > support for multiple"... is very long and hard to parse. I suspect it > will be hard to translate. The action of changing the existing protocols > is implied rather than explicit in the current wording. "current > designs" is vague. I suggest this as a starting point: "Adding support > for multiple QoS-based traffic classes within a single network 5-tuple > to a transport protocol adds significant complexity compared to the > current protocol definitions. For congestion-controlled transport > protocols, network congestion information for each QoS-based traffic > class would have to be disambiguated to allow congestion control to be > managed separately for each such traffic class." Hopefully it can be > made even simpler. Indeed, that sentence is problematic. I've edited the entire paragraph for clarity. Here's the new text: When PHBs that enable reordering are mixed within a single network 5-tuple, the effect is to mix QoS-based traffic classes within the scope of a single transport protocol connection or association. As these QoS-based traffic classes receive different network QoS treatments, they use different pools of network resources and hence may exhibit different levels of congestion. The result for congestion-controlled protocols is that a separate instance of congestion control functionality is needed per QoS-based traffic class. Current transport protocols support only a single instance of congestion control functionality for an entire connection or association; extending that support to multiple instances would add significant protocol complexity. Traffic in different QoS-based classes may use different paths through the network; this complicates path integrity checking in connection- or association-based protocols, as those paths may fail independently. > In the first paragraph of 5.2, would "Such reordering may lead to > unneeded retransmission, and spurious emission of retransmission control > signals (such as NACK) in reliable delivery protocols (see Section 5.1)" > work? Yes, and I've removed "emission of" from that proposed text. Thanks, --David > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@xxxxxxxxxxx] > Sent: Tuesday, October 14, 2014 11:50 AM > To: General Area Review Team; draft-ietf-dart-dscp-rtp.all@xxxxxxxxxxxxxx; > ietf@xxxxxxxx; dart@xxxxxxxx > Subject: Gen-art LC review: draft-ietf-dart-dscp-rtp-07 > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-dart-dscp-rtp-07 > Reviewer: Robert Sparks > Review Date: 14-Oct-2014 > IETF LC End Date: 14-Oct-2014 > IESG Telechat date: not yet scheduled for a telechat > > Summary: Ready with nits > > These are very small nits to consider. Please feel free to leave the > existing text alone if these suggestions don't help. > > At the end of page 13, the sentence that starts "Transport protocol > support for multiple"... is very long and hard to parse. I suspect it > will be hard to translate. The action of changing the existing protocols > is implied rather than explicit in the current wording. "current > designs" is vague. I suggest this as a starting point: "Adding support > for multiple QoS-based traffic classes within a single network 5-tuple > to a transport protocol adds significant complexity compared to the > current protocol definitions. For congestion-controlled transport > protocols, network congestion information for each QoS-based traffic > class would have to be disambiguated to allow congestion control to be > managed separately for each such traffic class." Hopefully it can be > made even simpler. > > In the first paragraph of 5.2, would "Such reordering may lead to > unneeded retransmission, and spurious emission of retransmission control > signals (such as NACK) in reliable delivery protocols (see Section 5.1)" > work? > >