Skip to main content

RTP Control Protocol (RTCP) Feedback for Congestion Control


(Barry Leiba)

No Objection

Murray Kucherawy
(Alissa Cooper)
(Alvaro Retana)
(Deborah Brungard)
(Martin Vigoureux)

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

Erik Kline
No Objection
Comment (2020-09-19 for -08) Sent
[[ questions ]]

[ section 3.1 ]

* If L=0, do we need text about how to treat report entries with
  non-zero ECN and ATO fields?

  Separately, what's a good mnemonic for "L"?  My instinct was to treat it
  as the "Loss" bit, but with the meaning the values 0 and 1 reversed that
  doesn't actually work very well.

[[ nits ]]

[ section 1 ]

* "to have generic...format" -> "to have a generic...format", perhaps

[ section 3.1 ]

* "sent previous reports" -> "previous reports sent", perhaps?

[ section 7 ]

* "a=ecn-capaable-rtp:" -> "a=ecn-capable-rtp:"

[ section 8 ]

* "ECN marking marking information" -> "ECN marking information"
Murray Kucherawy
No Objection
Roman Danyliw
No Objection
Comment (2020-09-23 for -08) Not sent
Thanks to the SECDIR reviewer, Linda Dunbar.
Warren Kumari
No Objection
Comment (2020-09-23 for -08) Not sent
No objection, but I'm wondering how Rob knows that this isn't actually 5 1/2 bits?! :-P
Éric Vyncke
No Objection
Comment (2020-09-22 for -08) Sent
Thank you for the work put into this document.

Please find below a couple of non-blocking COMMENT points and nits.

I hope that this helps to improve the document,




-- Section 3.1 --
In "but overlapping reports MAY be sent (and need to be sent in cases" should the "need" be a "MUST" ?

-- Section 5 --
In "then the sender SHOULD rapidly reduce", "sender" is somehow ambiguous: is it the feedback transmitter or the media source sender ?

-- Section 6 --
The mandatory use of "*" appears strange to the non-SDP expert (like myself). Why transmitting something that is always identical? What is the value ?
== NITS ==
-- Section 3.1 --
As some reader may also wonder like me, why the use of 'L' (at least I am puzzled)? why not giving one word mnemonic to explain the logic behind this choice ?

-- Section 7 --
Is there a typo in ""a=ecn-capaable-rtp:"" ?

it is probably redundant to again expand ECN.
Barry Leiba Former IESG member
Yes (for -08) Unknown

Benjamin Kaduk Former IESG member
Yes (2020-09-23 for -08) Sent
Section 1

   control designs are not interoperable.  To enable algorithm evolution
   as well as interoperability across designs (e.g., different rate
   adaptation algorithms), it is highly desirable to have generic
   congestion control feedback format.

nit: singular/plural mismatch "format"/"to have generic".

   To help achieve interoperability for unicast RTP congestion control,
   this memo proposes a common RTCP feedback packet format that can be

(side note) is there work underway for non-unicast RTP congestion

Section 2

   In addition the terminology defined in [RFC3550], [RFC3551],
   [RFC3611], [RFC4585], and [RFC5506] applies.

[3551 and 3611 don't seem to have prominent dedicated "definitions"

Section 3.1

   o  L (1 bit): is a boolean to indicate if the packet was received. 0
      represents that the packet was not yet received and all the
      subsequent bits (ECN and ATO) are also set to 0.  1 represents
      that the packet was received and the subsequent bits in the block
      need to be parsed.

(side note) it's tempting to parse this as the "loss bit", but then a
value of true means not-lost and false means lost, which feels somewhat
unnatural.  That said, preserving all-bits-zero as "no data" is probably
worth the tradeoff...

   sent previous reports for RTP packets included in both reports.  If
   an RTP packet was reported as received in one report, that packet
   MUST also be reported as received in any overlapping reports sent
   later that cover its sequence number range.

What should a recipient do if this invariant is violated?  Tear down the
RTP session as a protocol violation?

Section 4

   feedback, using a feedback interval range of 50-200ms.  Applications
   need to negotiate an appropriate congestion control feedback interval
   at session setup time, based on the choice of congestion control
   algorithm, the expected media bit rate, and the acceptable feedback

Are there protocol mechanisms standardized that can perform this
negotiation?  (I note that though we provide SDP signalling for the use
of CCFB overall, we do not define SDP signalling for the feedback

Section 7

   provides duplicate information.  Accordingly, when congestion control
   feedback is to be used with RTP and ECN, the SDP offer generated MUST
   include an "a=ecn-capable-rtp:" attribute to negotiate ECN support,
   along with an "a=rtcp-fb:" attribute with the "ack" parameter "ccfb"
   to indicate that the RTP Congestion Control Feedback Packet is to be
   used for feedback.  The "a=rtcp-fb:" attribute MUST NOT include the
   "nack" parameter "ecn", so the RTCP ECN Feedback Packet will not be

Am I reading this correctly that a "mixed" deployment with Offerer that
supports both mechanisms and an Answerer that only supports RFC 6679
will result in ECN not being used for the RTP session at all, even
though 6679 is supported by both parties?  Why does it not suffice to
only constrain the Answer behavior?

Section 8

      control.  TMMBR could, however, be viewed a complementary
      mechanism that can inform the sender of the receiver's current
      view of acceptable maximum bit rate.  The Received Estimated
      Maximum Bit-rate (REMB) mechanism [I-D.alvestrand-rmcat-remb]
      provides similar feedback.

The REMB I-D expired in 2014; is it still useful to reference it by name
(as opposed to a representative of a class)?  Contrast to
draft-holmer-rmcat-transport-wide-cc-extensions, which expired in 2016,
but we reference only as an example of the class of schemes that adds a
transport-wide sequence number to each RTP packet.

   RTCP Extended Reports (XR):  Numerous RTCP extended report (XR)
      blocks have been defined to report details of packet loss, arrival
      times [RFC3611], delay [RFC6843], and ECN marking [RFC6679].  It
      is possible to combine several such XR blocks into a compound RTCP
      packet, to report the detailed loss, arrival time, and ECN marking
      marking information needed for effective sender-based congestion
      control.  However, the result has high overhead both in terms of
      bandwidth and complexity, due to the need to stack multiple

If I am reading correctly, RFC 6679 only provides ECN counters, not
necessarily at packet granularity, so it may not actually provide as
much information as this mechanism.

Section 9

Are the named individuals the members of the design team?  If not, where
can the membership of the design team be determined?

Section 11

I look forward to the clarification regarding off-path attacks produced
in response to the tsv-art review.

In theory the exposure of (somewhat) fine-grained timing information at
per-packet granularity could open up new attacks that look for side
channels in processing of other protocols operating between the same
endpoints, but I am not really convinced that millisecond-scale
information presents enough exposure to merit mentioning here.

   congestion on the path.  This will negatively impact the quality of
   experience of that receiver.  Since RTP is an unreliable transport, a

And potentially other entities using the bottleneck segment of that
path? Also could potentially cause excessive resource consumption on the

   sender can intentionally leave a gap in the RTP sequence number space
   without causing harm, to check that the receiver is correctly
   reporting losses.

[I assume that recommended remediation measures in the face of such a
lying peer are covered in the referenced documents already.]

   An on-path attacker that can modify RTCP congestion control feedback
   packets can change the reports to trick the sender into sending at
   either an excessively high or excessively low rate, leading to denial
   of service.  The secure RTCP profile [RFC3711] can be used to
   authenticate RTCP packets to protect against this attack.

I guess to try to do this off-path you'd need to guess the SSRCs and
sequence-numbers (mod 2**16) in addition to transport ports, which
quickly becomes infeasible if there's more than one stream, so it really
is just an off-path threat.

Section 12.1

It seems that we only list 3611 as normative for the terminology
reference, but I didn't see any terminology usage that we clearly needed
3611 for.
Alissa Cooper Former IESG member
No Objection
No Objection (for -08) Not sent

Alvaro Retana Former IESG member
No Objection
No Objection (for -08) Not sent

Deborah Brungard Former IESG member
No Objection
No Objection (for -08) Not sent

Magnus Westerlund Former IESG member
(was Discuss) No Objection
No Objection (2020-11-03) Sent
Thanks for addressing my issues.
Martin Duke Former IESG member
No Objection
No Objection (2020-09-21 for -08) Sent
It sounds like Colin is addressing the tsvart review, so thanks.

In section 5, can you clarify (or provide a reference) how to detect RTCP packet loss? Is this simply a matter of receiving them at less than the configured rate?
Martin Vigoureux Former IESG member
No Objection
No Objection (for -08) Not sent

Robert Wilton Former IESG member
No Objection
No Objection (2020-09-22 for -08) Sent

Thanks for this document, I found it pretty easy to read, and it looks useful.

One minor nit on your packet diagram:
Due to where the '|' character is, it looks like the FMT-CCFB field is 5 and half bits long, which probably isn't intended!