Skip to main content

Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences
RFC 9392


Zaheduzzaman Sarker

No Objection

Andrew Alston
Erik Kline

Note: This ballot was opened for revision 11 and is now closed.

Zaheduzzaman Sarker
Éric Vyncke
Comment (2022-10-18 for -11) Sent
Thanks for this document, while I am not a transport person, it was readable and clearly written.

I can only regret the exclusive use of IPv4 in the tables, especially for VoIP where the larger IPv6 header could have a more negative impact.

Please do like in section 3.1 for the section 3.2 text "The RTCP SR packet contains the 28 octet header and sender" (i.e., specify IPv4 no IP options).


Andrew Alston
No Objection
Erik Kline
No Objection
John Scudder
No Objection
Comment (2022-10-19 for -11) Sent
Thanks for an interesting read. One question --

### Section 3.2

I don't quite follow what you mean by "frame of packet" in

   that video has constant bit rate and frame rate, and that each frame
   of packet has to fit into a 1500 octet MTU.  

Presumably "frame rate" means video frames, not network frames. But "frame of packet"?
Lars Eggert
No Objection
Comment (2022-10-20 for -11) Sent
# GEN AD review of draft-ietf-rmcat-rtp-cc-feedback-11

CC @larseggert

Thanks to Linda Dunbar for the General Area Review Team (Gen-ART) review

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via, so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Boilerplate

Document still refers to the "Simplified BSD License", which was corrected in
the TLP on September 21, 2021. It should instead refer to the "Revised BSD

### Outdated references

Document references `draft-ietf-tcpm-RFC793bis`, but that has been published as

### Grammar/style

#### Section 2, paragraph 6
e feedback and data packets are sent and the feedback is similar in size to
Use a comma before "and" if it connects two independent clauses (unless they
are closely connected and short).

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

Martin Duke
No Objection
Comment (2022-10-19 for -11) Sent
Please update the rfc793bis reference to RFC9293.
Murray Kucherawy
No Objection
Comment (2022-10-19 for -11) Sent
Thanks to Bernard Aboba for his ARTART review.

I concur with Alvaro's point about normative references.
Robert Wilton
No Objection
Comment (2022-10-17 for -11) Sent
Thanks for this.  An informative read.

Roman Danyliw
No Objection
Comment (2022-10-18 for -11) Not sent
Thank you to Linda Dunbar for the SECDIR review.

Section 3.1.  Per “A rate adaptive speech codec, such as Opus ...”, please provide a reference for “Opus”.
Alvaro Retana Former IESG member
No Objection
No Objection (2022-10-17 for -11) Sent
It caught my attention that this document has no Normative references, which are documents "that must be read to understand...the technology in the new RFC" [1].

In this case, it looks like most of the RFCs cited in the Introduction should be Normative:

   The deployment of WebRTC systems [RFC8825] has resulted in high-
   quality video conferencing seeing extremely wide use.  ...

   To develop such congestion control, it is necessary to understand the
   sort of congestion feedback that can be provided within the framework
   of RTP [RFC3550] and the RTP Control Protocol (RTCP).  It then
   becomes possible to determine if this is sufficient for congestion
   control, or if some form of RTP extension is needed.

   This memo considers unicast congestion feedback that can be sent
   using RTCP under the RTP/SAVPF profile [RFC5124] (the secure version
   of the RTP/AVPF profile [RFC4585]).  This profile was chosen as it
   forms the basis for media transport in WebRTC [RFC8834] systems.
   Nothing in this memo is specific to the secure version of the
   profile, or to WebRTC, however.  It is also assumed that the
   congestion control feedback mechanism described in [RFC8888], and
   common RTCP extensions for efficient feedback [RFC5506], [RFC8108],
   [RFC8861], and [RFC8872] are used.