Re: [Dart] Gen-art LC review: draft-ietf-dart-dscp-rtp-07

["Black, David" <[e-mail]>]

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:[e-mail]]
> Sent: Tuesday, October 14, 2014 11:50 AM
> To: General Area Review Team; [e-mail];
> [e-mail]; [e-mail]
> 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?
> 
>