Sending RTP Control Protocol (RTCP) Feedback for Congestion Control in Interactive Multimedia Conferences
draft-ietf-rmcat-rtp-cc-feedback-12

Thanks for an interesting read. One question --

### Section 3.2

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

```
   Assume
   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"?

Thanks to Bernard Aboba for his ARTART review.

I concur with Alvaro's point about normative references.

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

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.



[1] https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/

# 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
(https://mailarchive.ietf.org/arch/msg/gen-art/IlQmtbncyGJ1B6qPc-IdbuGSqEA).

## 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 https://github.com/larseggert/ietf-reviewtool), 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
License".

### Outdated references

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

### 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].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

Please update the rfc793bis reference to RFC9293.

Thanks for this.  An informative read.

Regards,
Rob