Re: [Last-Call] Artart last call review of draft-ietf-rmcat-rtp-cc-feedback-10

[Colin Perkins <[e-mail]>]

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 Issues
>
> Reviewer: Shuping Peng
> Review Result: Ready with Issues
>
> I 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