[rmcat] Artart last call review of draft-ietf-rmcat-rtp-cc-feedback-10

Shuping Peng via Datatracker <noreply@ietf.org> Tue, 09 August 2022 08:03 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: rmcat@ietf.org
Delivered-To: rmcat@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 74A0DC15A734; Tue, 9 Aug 2022 01:03:40 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Shuping Peng via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-rmcat-rtp-cc-feedback.all@ietf.org, last-call@ietf.org, rmcat@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 8.12.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <166003222046.58655.11877444893849918494@ietfa.amsl.com>
Reply-To: Shuping Peng <pengshuping@huawei.com>
Date: Tue, 09 Aug 2022 01:03:40 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/bv6i8gljJTYh_qNTY9DyurHeVAA>
Subject: [rmcat] Artart last call review of draft-ietf-rmcat-rtp-cc-feedback-10
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.39
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Aug 2022 08:03:40 -0000

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."

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".

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."

It would be better to provide a reference for "RTCP reception quality
feedback", e.g. [RFC7201]?

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.

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."

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.

Section 4:

What are the "other media topologies"? It would be good to give some examples
and references.

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.

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

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

Section 3:

s/comprise a 2 octet header/comprise a 2-octet header

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

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?

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.

s/The use of reduced-size RTCP gives a noticeable reduction
/The use of reduced-size RTCP reports gives a noticeable reduction

* Section 4

s/close to it's current form/close to its current form