On 10/14/14 1:18 PM, Black, David wrote:
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.
That's great. Thanks!
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.
Ack
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?