Explicit Congestion Notification (ECN) for RTP over UDP
updated by
- rfc-8311 — Relaxing Restrictions on Explicit Congestion Notification (ECN) Experimentation
Extracted elements (29)
ECN support for RTP is more important than for TCP because packet loss in real-time audio-visual media is highly visible to users and cannot be repaired by retransmission. ECN allows applications to reduce transmission rate before routers drop packets, preserving media quality in a controlled manner.
Multicast ECN support is conservative: all known receivers must demonstrate ECN capability before the sender may send ECN-marked packets, because allowing some non-ECN-capable receivers creates fairness issues when the bottleneck link is shared between ECN and non-ECN flows.
RTCP ECN feedback counts the number of ECN-CE marked packets rather than flipping a single bit per RTT as TCP does. This is because real-time applications need to distinguish between a burst of congestion marks and a single mark, and RTCP reporting periods are not aligned with RTTs.
Two RTCP mechanisms serve different roles: the AVPF feedback packet (Section 5.1) provides low-latency but less reliable per-event notification of ECN-CE marks, while the XR Summary Report (Section 5.2) provides reliable cumulative reporting using independent counters unaffected by RTCP packet loss.
An ECN-unaware legacy RTP translator is expected to ignore ECN bits on received packets and set ECN bits to not-ECT on sending, causing ECN negotiation to fail on any path containing such a translator. New translators that do not support ECN should behave similarly.
The 'a=ecn-capable-rtp:' attribute MUST NOT be used for RTP sessions using TCP, SCTP, or DCCP transport or for non-RTP sessions, since those transports have native ECN support. It is only applicable to RTP sessions over UDP/IP.
The in-band RTP/RTCP initiation method (Section 7.2.1) is selected as the mandatory-to-implement method because it works in all deployment scenarios regardless of topology, even though it is not optimal for all uses (it may cause media clipping if ECN-marked packets are dropped by middleboxes).
All session participants connected over the same transport MUST use the same ECN initiation method. RTP mixers or translators may use different initiation methods for participants connected over different underlying transports.
An RTP system that supports ECN MUST implement the in-band ECN initiation method using RTP and RTCP (Section 7.2.1) as the mandatory-to-implement initiation method. Additional methods such as ICE/STUN or leap-of-faith are optional.
Due to the need for each RTP sender to track all participants, the sub-sampling of group membership as specified by RFC 2762 MUST NOT be used when ECN is employed with RTP.
During the ECN initiation phase, an RTP sender SHALL mark a small fraction of its RTP traffic as ECT while leaving the remainder unmarked, and is RECOMMENDED to send a minimum of two packets with ECT markings per RTCP reporting interval.
Each regular RTCP report MUST also contain an ECN Summary Report (Section 5.2) to ensure reliable, if less timely, reporting of ECN marking information alongside standard reception reports.
If ECN capability has been negotiated, receivers MUST listen for ECT or ECN-CE marked RTP packets and generate RTCP ECN feedback packets. Reception of ECN-CE-marked packets MUST result in additional early or immediate ECN feedback packets being sent unless no timely feedback is required.
No matter how ECN usage is initiated, the sender MUST continually monitor the ability of the network and all its receivers to support ECN, as path changes or receiver population changes may invalidate ECN usability.
On receipt of an ECN-CE-marked packet, the system must react to congestion as if packet loss has been reported, providing the clearest possible congestion signal to the sender.
RTCP reports MUST NOT be ECT marked at any time, since ECT-marked traffic may be dropped if the path is not ECN compliant, and RTCP is needed to provide feedback even when ECT-marked RTP traffic is not getting through.
The 'a=ecn-capable-rtp:' SDP attribute is a media-level attribute and MUST NOT be used at the session level. It MUST be used when employing ECN for RTP in SDP-based systems. The 'rtcp-xr' attribute with 'ecn-sum' parameter MUST also always be used.
The Topo-Video-switch-MCU topology is NOT RECOMMENDED for new implementations and SHALL NOT be used with ECN, since a video-switching MCU drops packets based on voice activity rather than congestion, breaking ECN negotiation and feedback.
Use of the Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) or a profile that inherits its signalling rules MUST be signalled unless timely feedback is not required. Its use is RECOMMENDED even when timely feedback is not required.
The 'a=ecn-capable-rtp:' SDP attribute negotiates ECN use for RTP sessions. It includes an ordered list of preferred initiation methods (rtp, ice, leap) and optional parameters including 'mode=' (setread/setonly/readonly) and 'ect=' (0/1/random) indicating endpoint ECN capabilities.
The STUN ECN-CHECK attribute is a comprehension-optional STUN attribute used in ICE-based ECN verification. It is sent in an ECT-marked STUN request and echoed back in the response with the received ECN field value, allowing path ECN capability verification before media transmission.
Three ECN initiation methods are defined: (1) using RTP probe packets with RTCP feedback (mandatory-to-implement), (2) using ECT-marked STUN within ICE for faster pre-media verification (optional), and (3) a leap-of-faith method assuming ECN works without pre-verification (optional, restricted use).
Seven IANA registrations are created or updated: new SDP attribute 'ecn-capable-rtp:', RTP/AVPF Transport-Layer Feedback Message FMT=8 for ECN feedback, RTCP feedback SDP parameter 'nack ecn', RTCP XR Report Block type BT=13 for ECN Summary, RTCP XR SDP parameter 'ecn-sum', STUN attribute ECN-CHECK, and ICE option 'rtp+ecn'.
Leap-of-faith ECN initiation poses a severe risk: if a middlebox discards ECN-marked packets, all media could be lost. Even when ECN-reverting middleboxes are present, congestion responsiveness is impaired since applications fall back to packet loss as the only congestion signal, potentially increasing congestion.
The ECN feedback mechanism creates potential for cheating by both sender and receiver. A receiver could falsely report ECN-CE marks to throttle the sender, or falsely omit reports to let a congestion-causing sender continue. The mechanism includes counter-based verification (comparing ECT sent vs. ECT received) to detect such manipulation.
ECN initiation using RTP/RTCP transitions through probe, feedback collection, and determination states. Success requires stable group membership (at least 3 RTCP intervals) with all known participants having sent ECN feedback confirming ECT receipt. Failure is declared when a participant's RTCP report indicates it should have received >3 ECT packets but contains no ECN feedback.
The ECN-CHECK STUN attribute is a 32-bit comprehension-optional attribute containing: 29 reserved bits (set to 0), a 2-bit ECN Echo value field (ECF), and a 1-bit Valid flag (V) indicating whether the ECF contains a valid echoed ECN value.
The RTCP XR ECN Summary Report block (BT=13) contains per-SSRC data blocks each with: SSRC of Media Sender (32-bit), ECT(0) Counter (32-bit), ECT(1) Counter (32-bit), ECN-CE Counter (16-bit), not-ECT Counter (16-bit), Lost Packets Counter (16-bit), and Duplication Counter (16-bit). Block Length must be a multiple of five 32-bit words.
The RTP/AVPF ECN Feedback Report (FMT=8, PT=205) contains six fields: a 32-bit Extended Highest Sequence Number, 32-bit ECT(0) Counter, 32-bit ECT(1) Counter, 16-bit ECN-CE Counter, 16-bit not-ECT Counter, 16-bit Lost Packets Counter, and 16-bit Duplication Counter; all counters are cumulative and initialized to 0.