Hi Shuping,
Thank you for your review, and apologies for my slow follow-up.
On 9 Aug 2022, at 9:03, Shuping Peng via Datatracker wrote:
Reviewer: Shuping Peng
Review result: Ready with IssuesReviewer: Shuping Peng
Review Result: Ready with IssuesI am the assigned ART-ART reviewer for this draft
(draft-ietf-rmcat-rtp-cc-feedback-10).Summary:
I have some minor concerns about this document that I think should be resolved
before publication.Major Issues:
"No major issues found."
Thanks.
Minor Issues:
Abstract:
"This memo discusses the types of congestion control feedback that it is
possible to send using the RTP Control Protocol (RTCP), and their suitability
of use in implementing congestion control for unicast multimedia applications."It is not clear what are the types of congestion control feedback considered in
this draft. In Section 2, the "RTCP reception quality feedback" is mentioned
but only once, while in the rest of this draft, "RTCP congestion control
feedback" is considered [8888]. It seems that the "RTCP reception quality
feedback" is directly taken as the "RTCP congestion control feedback".
RTCP provides several types of reception quality feedback. Congestion control feedback is one such type. I’ve changed the start of Section 2, to now say “when providing RTCP feedback for congestion control purpose” to clarify.
A proposal for the abstract of this draft, just for the author's reference:
"This memo discusses the types of RTCP feedback that it is possible to send for
the congestion control purposes, and their suitability of use in implementing
congestion control for unicast multimedia applications."
That change would work, but re-reading the abstract I think a more important change would be to highlight the rate of which congestion control feedback is sent, not the type of feedback. I’ve changed it to:
This memo discusses the rate at which congestion control feedback can
be sent using the RTP Control Protocol (RTCP) and its suitability for
implementing congestion control for unicast multimedia applications.
It would be better to provide a reference for "RTCP reception quality
feedback", e.g. [RFC7201]?
No, that’s discussing a different topic. The references for RTCP reception quality feedback are RFCs 3550, 3611, and 4585, which are already cited by this draft.
Section 2:
"The RTP standards have long said that a 5% overhead for RTCP traffic is
generally acceptable, while providing the ability to change this fraction. Is
this still the case for congestion control feedback? "Is the congestion control feedback part of the overhead for RTCP traffic? If
yes, then this sentence seems to be redundant.
Congestion control feedback is part of the overhead for RTCP traffic.
The draft is discussing how that overhead changes when different amounts of congestion control feedback are sent, and what rates of congestion control feedback are possible while keeping the overhead within that 5% bound.
Or considering the context, maybe change it to something like, "The RTP
standards have long said that a 5% overhead for RTCP traffic, including
congestion feedback, is generally acceptable, while providing the ability to
change this fraction."
That’s an accurate statement of fact, but the draft is asking a question about whether the congestion control can fit within the 5% overhead often considered acceptable.
Section 3.1:
Just wonder whether the descriptions regarding the classification of the RTCP
feedback packets (i.e. full, compound, RTCP feedback packets, or reduced-size
RTCP packets in the 3rd/4th/... paragraph) could be listed out at the beginning
of the Section 3, since this information is referred in both following
scenarios.
It could be, but I think the document flows better with this information inline where it’s first used, rather than separated out at the start of the section.
Section 4:
What are the "other media topologies"? It would be good to give some examples
and references.
I added a reference to RFC 7667, which describes RTP topologies.
Nits:
* Section 2:
s/The key question is how often does the receiver need to send feedback on the
reception quality... of the network? /The key question is how often the
receiver needs to send feedback on the reception quality ... of the network.
I think the original is correct.
s/Approaches like in-network filtering of acknowledgements have been proposed
to reduce acknowledgement overheads ... can also /Approaches like in-network
filtering of acknowledgements that have been proposed to reduce acknowledgement
overheads ... can also
Fixed, thanks.
s/it might make sense to give the option of sending congestion feedback less
often than does TCP /it might make sense to give the option of sending
congestion feedback less often than TCP does
Fixed, thanks.
Section 3:
s/comprise a 2 octet header/comprise a 2-octet header
Fixed.
s/The RTCP congestion control feedback (CCFB) report comprises an 8 octet RTCP
header and SSRC, a 4 octet report timestamp, and for each of the remote audio
and video SSRCs, an 8 octet report header, and 2 octets per packet reported
upon, and padding to a 4 octet boundary if needed /The RTCP congestion control
feedback (CCFB) report comprises an 8-octet RTCP header and SSRC, a 4-octet
report timestamp, and for each of the remote audio and video SSRCs, an 8-octet
report header, and 2 octets per packet reported upon, and padding to a 4-octet
boundary if needed
Fixed.
s/How many RTP packets does the RTCP XR congestion control feedback
packet included in these compound RTCP packets report on?
/How many RTP packets does the RTCP XR congestion control feedback
packet include in these compound RTCP packets report on?
I think the original was correct, but I added some punctuation to clarify.
s/alternating compound and reduced-size reports gives results as shown in Table
4. /alternating compound and reduced-size reports give results as shown in
Table 4.
The original is correct.
s/The use of reduced-size RTCP gives a noticeable reduction
/The use of reduced-size RTCP reports gives a noticeable reduction
Both are correct.
* Section 4
s/close to it's current form/close to its current form
Fixed. The apostrophe is hard :-)
Cheers,
Colin
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
