RFC 6679
Explicit Congestion Notification (ECN) for RTP over UDP
RFC 6679: Explicit Congestion Notification (ECN) for RTP over UDP 💖
okay bestie, this is RFC 6679 and it's giving real-time media 🎀. It's an IETF (Internet Engineering Task Force) document in the Standards Track category, so it's an official spec, not just a vibe. It was written by M. Westerlund and I. Johansson (Ericsson), C. Perkins (University of Glasgow), P. O'Hanlon (University of Oxford), and K. Carlberg (G11). It's dated August 2012, has ISSN 2070-1721, and its title block doesn't list anything it obsoletes or updates ✨.
Abstract
okay so the big idea 🦋: this memo explains how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using the RTP Control Protocol (RTCP) as the feedback mechanism. It defines a brand new RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP transport feedback message for timely reporting of congestion events, and a Session Traversal Utilities for NAT (STUN) extension used in the optional initialisation method using Interactive Connectivity Establishment (ICE). It also defines the signalling and procedures for negotiating capabilities and initialisation methods 💅.
Status of This Memo
this is an Internet Standards Track document, and it's a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community, it went through public review, and the Internet Engineering Steering Group (IESG) approved it for publication 🌸. For more on Internet Standards, check Section 2 of RFC 5741.
info about the current status, any errata, and how to send feedback lives at http://www.rfc-editor.org/info/rfc6679 🧚.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved 🌈.
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please read these carefully, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶.
Table of Contents
1. Introduction ....................................................4
2. Conventions, Definitions, and Acronyms ..........................5
3. Discussion, Requirements, and Design Rationale ..................6
3.1. Requirements ...............................................8
3.2. Applicability ..............................................8
3.3. Interoperability ..........................................12
4. Overview of Use of ECN with RTP/UDP/IP .........................13
5. RTCP Extensions for ECN Feedback ...............................16
5.1. RTP/AVPF Transport-Layer ECN Feedback Packet ..............16
5.2. RTCP XR Report Block for ECN Summary Information ..........19
6. SDP Signalling Extensions for ECN ..............................21
6.1. Signalling ECN Capability Using SDP .......................21
6.2. RTCP ECN Feedback SDP Parameter ...........................26
6.3. XR Block ECN SDP Parameter ................................26
6.4. ICE Parameter to Signal ECN Capability ....................27
7. Use of ECN with RTP/UDP/IP .....................................27
7.1. Negotiation of ECN Capability .............................27
7.2. Initiation of ECN Use in an RTP Session ...................28
7.3. Ongoing Use of ECN within an RTP Session ..................35
7.4. Detecting Failures ........................................38
8. Processing ECN in RTP Translators and Mixers ...................42
8.1. Transport Translators .....................................42
8.2. Fragmentation and Reassembly in Translators ...............43
8.3. Generating RTCP ECN Feedback in Media Transcoders .........45
8.4. Generating RTCP ECN Feedback in Mixers ....................46
9. Implementation Considerations ..................................47
10. IANA Considerations ...........................................47
10.1. SDP Attribute Registration ...............................47
10.2. RTP/AVPF Transport-Layer Feedback Message ................47
10.3. RTCP Feedback SDP Parameter ..............................48
10.4. RTCP XR Report Blocks ....................................48
10.5. RTCP XR SDP Parameter ....................................48
10.6. STUN Attribute ...........................................48
10.7. ICE Option ...............................................48
11. Security Considerations .......................................48
12. Examples of SDP Signalling ....................................51
12.1. Basic SDP Offer/Answer ...................................52
12.2. Declarative Multicast SDP ................................54
13. Acknowledgments ...............................................54
14. References ....................................................55
14.1. Normative References .....................................55
14.2. Informative References ...................................561. Introduction ✨
okay so this memo lays out how Explicit Congestion Notification (ECN) [RFC3168] can be used for Real-time Transport Protocol (RTP) [RFC3550] flows running over UDP/IP that use the RTP Control Protocol (RTCP) as a feedback mechanism 💜. The solution has three parts: feeding ECN congestion experienced markings back to the sender using RTCP, checking that ECN works end-to-end, and procedures for how to start using ECN. Since starting ECN depends on the signalling mechanism used to set up the RTP session, the memo also includes a spec for signalling with the Session Description Protocol (SDP) [RFC4566] 🎀.
ECN can be used to minimise the impact of congestion on real-time multimedia traffic 🔥. It gives the network a way to send congestion control signals to the media transport without having to hurt the media itself. Unlike packet loss, an ECN signal tells the transport about congestion as fast as the feedback delays allow, and it doesn't mix congestion up with losses that might have happened for other reasons, like transmission errors, packet-size errors, routing errors, badly implemented middleboxes, policy violations, and so forth 🙈.
bringing ECN into the Internet means changing both the network and transport layers. At the network layer, IP forwarding has to be updated so routers can mark packets instead of discarding them when things get congested [RFC3168]. At the transport layer, protocols have to be changed so they can tell the sender that ECN-marked packets are arriving, and then the sender can respond to the congestion. The Transmission Control Protocol (TCP) [RFC3168], Stream Control Transmission Protocol (SCTP) [RFC4960], and Datagram Congestion Control Protocol (DCCP) [RFC4340] have all been updated to support ECN. But so far, nothing describes how UDP-based transports, such as RTP [RFC3550], can use ECN 😭. The reason is that UDP doesn't have feedback mechanisms. Instead, the signalling control protocol on top of UDP has to provide that feedback, and for RTP, that feedback comes from RTCP 💅.
here's the roadmap 🗺️. Section 2 covers the conventions, definitions, and acronyms, and Section 3 covers the design rationale and applicability. Section 4 gives an overview of how ECN is used with RTP over UDP. RTCP extensions for ECN feedback are defined in Section 5, and SDP signalling extensions in Section 6. The nitty-gritty details of how ECN is used with RTP over UDP are in Section 7. In Section 8, we look at how ECN is handled in RTP translators and mixers. Section 9 discusses some implementation considerations, Section 10 lists IANA considerations, and Section 11 covers security considerations.
Finally, Section 12 provides some examples of SDP signalling for ECN feedback
2. Conventions, Definitions, and Acronyms 🌸
the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] 🔥.
Definitions and Abbreviations:
- Sender: A sender of RTP packets carrying an encoded media stream. The sender can change how the media transmission is performed by varying the media coding or packetisation. It is one endpoint of the ECN control loop 🦋.
- Receiver: A receiver of RTP packets with the intention to consume the media stream. It sends RTCP feedback on the received stream. It is the other endpoint of the ECN control loop 🧚.
- ECN-Capable Host: A sender or receiver of a media stream that is capable of setting and/or processing ECN marks ✨.
- ECN-Capable Transport (ECT): A transport flow where both sender and receiver are ECN-capable hosts. Packets sent by an ECN-capable transport will be marked as
ECT(0)orECT(1)on transmission. See [RFC3168] for the definition of theECT(0)andECT(1)marks 💜. - ECN-CE: ECN Congestion Experienced mark (see [RFC3168]) 🌈.
- ECN-Capable Packets: Packets with ECN mark set to either
ECT(0),ECT(1), orECN-CE🎀. - Not-ECT packets: Packets that are not sent by an ECN-capable transport and are not ECN-CE marked 🙈.
- ECN-Capable Queue: A queue that supports ECN-CE marking of ECN-capable packets to indicate congestion 👑.
- ECN-Blocking Middlebox: A middlebox that discards ECN-capable packets 💀.
- ECN-Reverting Middlebox: A middlebox that changes ECN-capable packets to not-ECT packets by removing the ECN mark 😭.
heads up bestie: RTP mixers or translators that operate in such a manner that they terminate or split the ECN control loop will take on the role of receivers or senders. This is further discussed in Section 3.2 🫶.
Part 1 of 14, more coming! 🌈💖
3. Discussion, Requirements, and Design Rationale ✨
okay so ECN has already been specced for TCP [RFC3168], SCTP [RFC4960], and DCCP [RFC4340] 💖 all three are unicast protocols that negotiate ECN during the initial connection handshake. that's how it gets rolled out gradually, and it's also how they check whether ECN-marked packets make it through every middlebox on the path 🦋 when a receiver sees an ECN-CE mark, it immediately echoes it back to the sender using an extra bit in its feedback messages. the sender then treats that mark just like a packet loss for congestion control purposes. iconic behavior honestly 👑
if RTP runs over TCP, SCTP, or DCCP, it can use the native ECN support those protocols already give it. this memo won't dig into those use cases any further 🌸 BUT RTP is way more commonly run over UDP, and that combo doesn't support ECN right now. it's also really different from the other transports ECN has been specced for 😭 here's the tea:
Signalling: RTP leans on separate signalling protocols to negotiate parameters before a session gets created. it doesn't have an in-band handshake or negotiation at session setup time. (basically there's no RTP version of the TCP three-way handshake 💀)
Feedback: RTP doesn't explicitly acknowledge receipt of datagrams 🙈 instead, the RTP Control Protocol (RTCP) handles reception quality feedback and other back channel communication for RTP sessions. the feedback interval is usually on the order of seconds, not once per network round-trip time (RTT). the RTP Audio-Visual Profile with Feedback (RTP/AVPF) profile [RFC4585] does allow faster feedback in most cases though ✨ and RTCP is very much about counting packets, which makes byte-counting congestion algorithms hard to use 😩
Congestion Response: it's possible to adapt the transmission of many audio/visual streams when the network gets congested, and that adaptation is required by [RFC3550] 🎀 but the dynamics of the congestion response can be pretty different from TCP or other transport protocols.
Middleboxes: the RTP framework explicitly supports mixers and translators, which are middleboxes that get involved in media transport functions 🧚
Multicast: RTP is explicitly a group communication protocol and was designed from the start to support IP multicast 🌈 mostly Any-Source Multicast (ASM) [RFC1112], although a more recent extension supports Source-Specific Multicast (SSM) [RFC3569] with unicast feedback [RFC5760] ✨
Application Awareness: when ECN support lives inside the transport protocol, the application has very little visibility into the transport layer, so its ability to react to congestion is limited 🥺 adding ECN support to RTP using RTCP feedback means the application actually knows about congestion. that opens up a wider range of reactions to the congestion indication 💅
Counting vs. Detecting Congestion: TCP and the protocols derived from it are mainly built to respond the same way whether they get a burst of congestion indications within one RTT or just a single one 🙄 real-time apps, though, care about how much congestion they experienced and whether it's spread out smoothly or hits in bursts 💜 when ECN feedback was added to TCP [RFC3168], the receiver flipped the echo congestion experienced (ECE) flag to 1 for a whole RTT and then flopped it back to zero. ECN feedback in RTCP, on the other hand, needs to report a count of how much congestion was experienced within an RTCP reporting period, regardless of round-trip times 🔥
these differences seriously change the shape of ECN support in RTP over UDP compared to ECN in TCP, SCTP, and DCCP 😤 but they don't cancel out the need for ECN support. ECN actually matters more for RTP sessions than for a lot of applications over TCP 🫶 packet loss in real-time audio-visual media is super visible to users. with TCP-based apps, TCP retransmits the lost packets, and even though a drop costs extra delay compared to an ECN-CE mark, the loss still gets repaired ✨ effective ECN support for RTP over UDP would let real-time audio-visual apps respond to the start of congestion before routers are forced to drop packets 🦋 that means apps can decide how to lower their transmission rate, and protect media quality, instead of scrambling to hide the effects of unpredictable packet loss. and if ECN and active queue management get widely deployed in routers (if that happens), it could cut down on unnecessary queuing delays, which lowers the RTT and helps interactive RTP apps like voice telephony 📞🌸
3.1. Requirements
okay bestie, let's talk requirements 🎀 if you think about ECN, transport protocols that support ECN, and RTP-based apps together, you can come up with a set of requirements. each one has to be satisfied to at least some degree if ECN is going to be used by RTP over UDP 💖
- REQ 1: A mechanism must exist to negotiate and initiate the use of ECN for RTP/UDP/IP sessions, so that an RTP sender will not send packets with ECT in the IP header unless it knows that all potential receivers will understand any ECN-CE indications they might receive. 🧚
- REQ 2: A mechanism must exist to feed back the reception of any packets that are ECN-CE marked to the packet sender. 🔁
- REQ 3: The provided mechanism should minimise the possibility of cheating, either by the sender or the receiver. 🙅♀️
- REQ 4: Some detection and fallback mechanism should exist to avoid loss of communication due to the attempted usage of ECN, in case an intermediate node clears ECT or drops packets that are ECT marked. 🛟
- REQ 5: Negotiation of ECN should not significantly increase the time taken to negotiate and set up the RTP session. (an extra RTT before the media can flow is unlikely to be acceptable for some use cases 😭)
- REQ 6: Negotiation of ECN should not cause media clipping at the start of a session. 🎤
the following sections describe how these requirements can be met for RTP over UDP 🦋✨
3.2. Applicability 🦋
okay so ECN with RTP over UDP only works if the sender and the receiver(s) both negotiate ECN capability AND every single element on the network path(s) gets checked for ECN support 🤝 RTP is used in a totally heterogeneous mix of network environments and topologies, with different signalling protocols, so the mechanisms here are built to verify ECN support in each of those environments, no matter the topology 💅
Due to the need for each RTP sender that intends to use ECN with RTP to track all participants in the RTP session, the sub-sampling of the group membership as specified by "Sampling of the Group Membership in RTP" [RFC2762] MUST NOT be used. 🙅♀️ every sender has to keep track of everyone, so no sub-sampling allowed, periodt.
the ECN use also depends on the RTP media flow being able to react to congestion signalled by ECN-marked packets 🌸 depending on the app, the media codec, and the network topology, that adaptation can happen in different forms and at different nodes. for example, the sender can change the media encoding, the receiver can change its subscription to a layered encoding, or either reaction can be handled by a transcoding middlebox. [RFC5117] identifies seven topologies in which RTP sessions may be configured, and they can affect whether ECN is usable ✨
Topo-Point-to-Point
this one is giving simple 🎀 it uses standard unicast flows. ECN may be used with RTP here in an analogous manner to how it's used with other unicast transport protocols, with RTCP carrying the ECN feedback messages.
Topo-Multicast
this one is a lot more complicated, bestie 😭 it's either an Any-Source Multicast (ASM) group [RFC3569] with potentially several active senders and multicast RTCP feedback, or a Source-Specific Multicast (SSM) group [RFC4607] with a single distribution source and unicast RTCP feedback from receivers. RTCP is designed to scale to large group sizes while avoiding feedback implosion (see Section 6.2 of [RFC3550], [RFC4585], and [RFC5760]), and a sender can use it to figure out if all its receivers, and the network paths to those receivers, support ECN (see Section 7.2). it's somewhat harder to tell if ALL network paths from ALL senders to ALL receivers support ECN, so we allow ECN to be used by an RTP sender using multicast UDP as long as the sender has verified that the paths to all its known receivers support ECN, no matter whether the paths from other senders to their receivers support it too ("all its known receivers" means all the synchronisation sources (SSRCs) from which the RTP sender has received RTP or RTCP in the last five reporting intervals, i.e., they haven't timed out) 🫶
Here's the tea ☕ group membership can change during the lifetime of a multicast RTP session, so new receivers that aren't ECN capable, or that have a path that doesn't support ECN, can show up. senders must use the mechanisms described in Section 7.4 to check that all receivers, and the network paths traversed to reach them, continue to support ECN, and they need to fall back to non-ECN use if any receivers join that don't. no notes 💀
SSM groups that use unicast RTCP feedback [RFC5760] do need a few extra considerations 👀 this topology can have multiple media senders that send traffic to the distribution source (DS) and are separated from the DS, and there can also be multiple feedback targets. the requirement for using ECN for RTP in this topology is that the media sender must be provided the feedback from the receivers, and that feedback may be in aggregated form from the feedback targets. We will not mention this SSM use case in the below text specifically, but when actions are required by the media source, they also apply to the SSM case where the RTCP feedback goes to the feedback target 🧚
The mechanisms defined in this memo support multicast groups, but they're known to be conservative and don't scale to large groups 😩 that's mainly because we require ALL members of the group to demonstrate that they can make use of ECN before the sender is allowed to send ECN-marked packets. allowing some non-ECN-capable receivers causes fairness issues when the bottleneck link is shared by ECN and non-ECN flows, and we haven't (yet) been able to satisfactorily address that. the rules regarding Determination of ECN Support in Section 7.2.1 may be relaxed in a future version of this specification to improve scaling once these issues have been resolved 🌈
Topo-Translator
a translator is an RTP-level middlebox that's invisible to the other participants in the RTP session (although it's usually visible in the associated signalling session) 🫥 there are two types: ones that don't modify the media stream and are concerned with transport parameters (like a multicast to unicast gateway), and ones that DO modify the media stream (like transcoding between different media codecs). a single RTP session traverses the translator, and the translator must rewrite RTCP messages passing through it to match the changes it makes to the RTP data packets. a legacy, ECN-unaware RTP translator is expected to ignore the ECN bits on received packets and set the ECN bits to not-ECT when sending packets, which makes ECN negotiation on the path containing the translator fail (any new RTP translator that doesn't want to support ECN may do so similarly) 🙅♀️ an ECN-aware RTP translator can act in one of three ways:
- if the translator does not modify the media stream, it should copy the ECN bits unchanged from the incoming to the outgoing datagrams, unless it is overloaded and experiencing congestion, in which case it may mark the outgoing datagrams with an ECN-CE mark. such a translator passes RTCP feedback unchanged. See Section 8.1.
- if the translator modifies the media stream to combine or split RTP packets but does not otherwise transcode the media, it must manage the ECN bits in a way analogous to that described in Section 5.3 of [RFC3168]. See Section 8.2 for details.
- if the translator is a media transcoder, or otherwise modifies the content of the media stream, the output RTP media stream may have radically different characteristics than the input RTP media stream. each side of the translator must then be considered as a separate transport connection, with its own ECN processing. this requires the translator to interpose itself into the ECN negotiation process, effectively splitting the connection into two parts with their own negotiation. once negotiation has been completed, the translator must generate RTCP ECN feedback back to the source based on its own reception, and must respond to RTCP ECN feedback received from the receiver(s) (see Section 8.3).
it's recognised that ECN and RTCP processing in an RTP translator that modifies the media stream is non-trivial 😤
Topo-Mixer
a mixer is an RTP-level middlebox that aggregates multiple RTP streams and mixes them together to generate a new RTP stream 🎶 the mixer is visible to the other participants in the RTP session and is usually visible in the associated signalling session too. the RTP flows on each side of the mixer are treated independently for ECN purposes, with the mixer generating its own RTCP ECN feedback and responding to ECN feedback for data it sends. since unicast transport between the mixer and any endpoint is treated independently, it would seem reasonable to let the transport on one side of the mixer use ECN while the transport on the other side is not ECN capable, if that's what's desired ✨ see Section 8.4 for details on how mixers should process ECN.
Topo-Video-switch-MCU
a video-switching Multipoint Control Unit (MCU) receives several RTP flows but forwards only one of them onwards to the other participants at a time 📺 the flow that gets forwarded changes during the session, often based on voice activity. since only a subset of the RTP packets generated by a sender get forwarded to the receivers, a video-switching MCU can break ECN negotiation (whether the negotiation succeeds may depend on the voice activity of the participant at the instant it takes place, shout if you want ECN). it also breaks congestion feedback and response, since RTP packets get dropped by the MCU depending on voice activity rather than network congestion 😭 this topology is widely used in legacy products, but it is NOT RECOMMENDED for new implementations and SHALL NOT be used with ECN. 🚫
Topo-RTCP-terminating-MCU
in this one, each participant runs an RTP point-to-point session between itself and the MCU 🌷 each of these sessions is treated independently for ECN and RTCP feedback purposes, so some can use ECN and some might not. very chill.
Topo-Asymmetric
it's theoretically possible to build a middlebox that's a combo of an RTP mixer in one direction and an RTP translator in the other 🤯 to quote [RFC5117], "This topology is so problematic and it is so easy to get the RTCP processing wrong, that it is NOT RECOMMENDED to implement this topology". bestie, just don't 🙈
These topologies may be combined within a single RTP session 🧩
The ECN mechanism defined in this memo is applicable to both sender- and receiver-controlled congestion algorithms 💖 the mechanism makes sure that both senders and receivers will know about ECN-CE markings and any packet losses, so the actual decision point for the congestion control isn't relevant. this is a huge benefit, because the rate of an RTP session can be varied in a bunch of ways. for example, a unicast media sender might use TCP Friendly Rate Control (TFRC) [RFC5348] or some other algorithm, while a multicast session could use a sender-based scheme that adapts to the lowest common supported rate, or a receiver-driven mechanism using layered coding to support more heterogeneous paths 🌈
To make sure ECN-CE-marked packets get timely feedback when needed, this mechanism requires support for the RTP/AVPF profile [RFC4585] or any of its derivatives, such as RTP/SAVPF [RFC5124] 💜 the standard RTP/AVP profile [RFC3551] doesn't allow any early or immediate transmission of RTCP feedback, and it has a minimal RTCP interval whose default value (5 seconds) is many times the normal RTT between sender and receiver. that's a whole lot of waiting, no thanks 🍓
3.3. Interoperability ✨
Okay bestie, interop is the whole vibe here 🫶. Every implementation needs at least one common way to initialise, so everyone can actually talk. The method that works in all cases is initialisation using RTP and RTCP (Section 7.2.1). It's not optimal for every use, but it's the one picked as the mandatory-to-implement method 💅. It needs both the RTCP XR extension and the ECN feedback format, and those need the RTP/AVPF profile to make sure feedback arrives in time 🦋.
Now here's the tea 🍓. When you look at every way ECN can be used with RTP, there are congestion control mechanisms that are receiver driven only (Section 7.3.3). These don't need timely feedback of congestion events to the sender, so they're kind of chill. If you pair one of those with an initialisation method that also doesn't need timely RTCP feedback, like the leap-of-faith method (Section 7.2.3) or the ICE-based method (Section 7.2.2), then neither the ECN feedback format nor RTP/AVPF would seem to be needed 🙈. BUT fault detection gets a huge glow-up with receiver-side detection (Section 7.4.1) plus early reporting of those cases through the ECN feedback mechanism ✨.
So for interop, we require implementing the RTP/AVPF profile, with both RTCP extensions and the signalling needed to support a common operations mode 👑. This spec recommends using RTP/AVPF in all cases, and the reasons are pretty iconic: negotiating the common interoperability point needs RTP/AVPF, mixing RTP/AVP and RTP/AVPF depending on other SDP attributes in the same media block is a whole mess, and fault detection gets better with RTP/AVPF 💖.
Using the ECN feedback format is also recommended 🌸. Still, there are situations where it isn't required, because timely feedback just isn't needed. These get explicitly marked with the phrase "no timely feedback required" 🧚. They usually show up alongside receiver-driven congestion control and the leap-of-faith and ICE-based initialisation methods. Also, if a receiver-driven congestion control solution still needs RTCP to signal any adaptation information back to the sender, it'll still need RTP/AVPF for timeliness, no exceptions 😭.
4. Overview of Use of ECN with RTP/UDP/IP ✨
Okay so the solution for using ECN with RTP over UDP/IP is made of four different pieces that work together as a team 👯♀️:
- Negotiation of the capability to use ECN with RTP/UDP/IP
- Initiation and initial verification of ECN-capable transport
- Ongoing use of ECN within an RTP session
- Handling of dynamic behaviour through failure detection, verification, and fallback
Before an RTP session can even exist, a signalling protocol gets used to negotiate, or at least configure, the session parameters (see Section 7.1) 💅. In some topologies, that signalling protocol can also be used to discover the other participants 🔍. One of the parameters that absolutely must be agreed on is whether a participant can support ECN. Just because everyone claims ECN support doesn't mean ECN is actually usable in the session, though 💀. There might be middleboxes on the path that don't pass ECN-marked packets, like a firewall that blocks traffic with the ECN bits set 🧱. This document defines the information that needs to be negotiated and gives a mapping to SDP, for use in both declarative and offer/answer contexts 📝.
When a sender joins a session where every participant claims ECN support, it needs to verify that the ECN support actually works 🕵️♀️. There are three ways to do that:
- The sender may generate a (small) subset of its RTP data packets with the ECN field of the IP header set to
ECT(0)orECT(1). Each receiver then sends an RTCP feedback packet reporting the reception of the ECT-marked RTP packets. Once the sender gets this feedback from every receiver it knows about, it can consider ECN functional for its traffic 🎀. Each sender does this verification independently. When a new receiver joins an existing RTP session, it sends RTCP reports in the usual manner. If those RTCP reports include ECN information, verification has succeeded, and sources can keep sending ECT packets 🦋. If not, verification fails, and each sender MUST stop using ECN (see Section 7.2.1 for details) 🚫. - Alternatively, ECN support can be verified during an initial end-to-end STUN exchange (for example, as part of ICE connection establishment) ✨. After connectivity has been verified without ECN capability, an extra STUN exchange happens, this time with the ECN field set to
ECT(0)orECT(1), on the candidate path that's about to be used. If it succeeds, the path's ability to convey ECN-marked packets is verified 🛣️. A new STUN attribute is defined to convey feedback that the ECT-marked STUN request was received (see Section 7.2.2), along with an ICE signalling option (Section 6.4) to indicate that the check is to be performed 🧚. - Thirdly, the sender may make a leap of faith that ECN will work 🪂. This is only recommended for applications that know they're running in controlled environments where ECN has been verified through other means 🏰. In this mode, it's assumed that ECN works, and the system reacts to failure indicators if that assumption turns out to be wrong 🚨. This method relies on high confidence that ECN operation will succeed, or on an application where failure isn't serious. The impact on the network and other users must be considered before making a leap of faith, so there are limits on when this method is allowed (see Section 7.2.3) ⚠️.
The first mechanism, using RTP with RTCP feedback, works for all RTP sessions, but it has a couple of downsides: potential clipping if ECN-marked RTP packets get discarded by middleboxes, and slow verification of ECN support 🐢. The STUN-based mechanism verifies ECN support faster, but it only works in scenarios supported by end-to-end STUN, such as within an ICE exchange 🏃♀️. The third one, the leap of faith, avoids additional tests and complexity and enables ECN usage from the very first media packet 🚀. The catch is that if the end-to-end path has middleboxes that don't pass ECN, the impact on the application can be severe: in the worst case, all media could be lost if a middlebox that discards ECN-marked packets is present 😱. A less severe effect, but still one that needs a reaction, is a middlebox that re-marks ECT-marked packets tonot-ECT, possibly marking packets with anECN-CEmark asnot-ECT. This can lead to increased congestion, because of non-responsiveness, and it hurts media quality since applications end up relying on packet loss as the indication of congestion 💔.
Once ECN support has been verified (or assumed) to work for all receivers, a sender marks all of its RTP packets as ECT packets 🌈. Meanwhile, receivers rapidly feed back reports on any ECN-CE marks to the sender using RTCP in RTP/AVPF immediate or early feedback mode, unless no timely feedback is required 🏎️. Each feedback report indicates the receipt of new ECN-CE marks since the last ECN feedback packet, and it also counts the total number of ECN-CE-marked packets as a cumulative sum 🔢. This is the mechanism for the fastest possible feedback to senders about ECN-CE marks ⚡. On receipt of an ECN-CE-marked packet, the system must react to congestion as if packet loss had been reported 📉. Section 7.3 describes the ongoing use of ECN within an RTP session 📖.
This rapid feedback isn't optimised for reliability, so another mechanism, RTCP XR ECN Summary Reports, is used to make ECN reporting more reliable, though less timely 🛡️. The ECN Summary Report contains the same information as the ECN feedback format, just packed differently for better efficiency when reporting on many sources 📦. It's sent in a compound RTCP packet, along with the regular RTCP reception reports 💌. By using cumulative counters for observed ECN-CE, ECT, not-ECT, packet duplication, and packet loss, the sender can work out what events have happened since the last report, even if some RTCP packets were lost 🧮.
RTCP reports MUST NOT be ECT marked, since ECT-marked traffic may be dropped if the path isn't ECN compliant 🙅♀️. RTCP is how feedback gets sent about what has been transmitted and which ECN markings were received, so it's important that it arrives even when ECT-marked traffic isn't getting through 📬.
There are plenty of reasons the path RTP packets take from sender to receiver might change, like mobility, or a link failure followed by re-routing around it 🗺️. That could send the packet through a node that isn't ECN compliant, which re-marks or drops packets with ECT set 😵. To keep this from hurting the application for longer than necessary, every sender constantly monitors ECN operation (Section 7.4) 👀. Both the RTCP XR ECN Summary Reports and the ECN feedback packets let the sender compare the number of ECT(0), ECT(1), and not-ECT-marked packets received against the number that were sent, while also reporting ECN-CE-marked and lost packets 📊. If those numbers don't agree, it can be inferred that the path doesn't reliably pass ECN-marked packets 🤔. A sender that detects a possible ECN non-compliance issue should then stop sending ECT-marked packets, to see whether that lets the packets get delivered correctly 🧪. If the issues can be tied to ECN, then ECN usage is suspended ⏸️.
5. RTCP Extensions for ECN Feedback ✨
This memo defines two brand-new RTCP extensions, and they're both iconic 👑. The first is one RTP/AVPF [RFC4585] transport-layer feedback format, for reporting urgent ECN information 🚨. The second is one RTCP XR [RFC3611] ECN Summary Report block type, for regular reporting of the ECN marking information 📅.
5.1. RTP/AVPF Transport-Layer ECN Feedback Packet
okay so this RTP/AVPF transport-layer feedback format is built for the RTP/AVPF early or immediate feedback modes, where info needs to reach the sender urgently 🚨 its main job is reporting that an ECN-CE-marked RTP packet showed up, so the sender can do congestion control 🦋 it also speeds up setup by quickly saying "hey, this path can handle ECN-marked traffic" ✨ the format is also designed with reduced-size RTCP [RFC5506] in mind, where feedback packets might get sent without any Sender or Receiver Reports, which normally carry the extended highest sequence number and the accumulated number of packet losses 🙈 both of those are super important for ECN, because they help verify it's working and keep track of when CE marking actually happens 💅
the packet kicks off with the common header from the RTP/AVPF profile [RFC4585], which you can see in Figure 1 🎀 the FMT field is set to 8, which tells you the Feedback Control Information (FCI) holds an ECN Feedback Report, as laid out in Figure 2 💖
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=8 | PT=RTPFB=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :Figure 1: RTP/AVPF Common Packet Format for Feedback Messages
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Highest Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lost Packets Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: ECN Feedback Report Format
The ECN Feedback Report has these fields: ✨
Extended Highest Sequence Number: this is the 32-bit extended highest sequence number received, as defined by [RFC3550] 🧚 it tells you the highest RTP sequence number this report is about.
ECT(0) Counter: the 32-bit cumulative number of RTP packets with ECT(0) received from this SSRC. 🌸
ECT(1) Counter: the 32-bit cumulative number of RTP packets with ECT(1) received from this SSRC. 🌸
ECN-CE Counter: the cumulative number of RTP packets received from this SSRC since the receiver joined the RTP session that were ECN-CE marked, including ECN-CE marks in any duplicate packets. the receiver should keep track of this value using a local representation that is at least 32 bits, and only include the 16 bits with least significance. in other words, the field wraps if more than 65535 ECN-CE-marked packets have been received. 🔥
not-ECT Counter: the cumulative number of RTP packets received from this SSRC since the receiver joined the RTP session that had an ECN field value of not-ECT. the receiver should keep track of this value using a local representation that is at least 32 bits, and only include the 16 bits with least significance. in other words, the field wraps if more than 65535 not-ECT packets have been received. 🍓
Lost Packets Counter: the cumulative number of RTP packets that the receiver expected to receive minus the number of packets it actually received that are not a duplicate of an already received packet, from this SSRC since the receiver joined the RTP session. packets that arrive late are not counted as lost 👑 the receiver should keep track of this value using a local representation that is at least 32 bits, and only include the 16 bits with least significance. in other words, the field wraps if more than 65535 packets are lost. 💀
Duplication Counter: the cumulative number of RTP packets received that are a duplicate of an already received packet from this SSRC since the receiver joined the RTP session. the receiver should keep track of this value using a local representation that is at least 32 bits, and only include the 16 bits with least significance. in other words, the field wraps if more than 65535 duplicate packets have been received. 🫶
All fields in the ECN Feedback Report are unsigned integers in network byte order 🧠 each ECN Feedback Report corresponds to a single RTP source (SSRC). if you want to report multiple sources, you include multiple ECN Feedback Report packets in an compound RTCP packet 💜
The counters SHALL be initiated to 0 for each new SSRC received. this is what lets you detect ECN-CE marks or packet loss on the very first report from a specific participant 🌈
Using at least 32-bit counters means even extremely high packet volume apps won't see wrapping within any timescale close to the RTCP reporting intervals, which is iconic 😭 but 32 bits aren't big enough to ignore the fact that wrapping can happen during the lifetime of a long-lived RTP session, so implementations need to be written to handle wrapping of the counters ⭐ it is recommended that implementations use a local representation of these counters that is longer than 32 bits, so wraps are easy to handle 🎀
ok this part is spicy 🌶️ the packet loss counter in the Receiver Report Block [RFC3550] is different from the one defined here when it comes to duplication. to avoid holding state for which RTP sequence numbers have been received, [RFC3550] says you can count packet loss by counting the received packets and comparing that to the number expected. which means a packet duplication can hide a packet loss 🙈 but when populating the ECN Feedback Report, a receiver needs to track the sequence numbers actually received and count duplicates and packet loss separately, so you get a more reliable indication ✨ reordering may, however, still make packet loss show up in one report and then disappear in the next 🌀
the ECN-CE counter is robust for packet duplication 💖 adding each received ECN-CE-marked packet to the counter is not an issue, and in fact it is required to ensure complete tracking of the ECN state 🔥 if one of the clones was ECN-CE marked, that still means congestion 🚨 packet duplication can affect ECN verification, so there's a need to count the duplicates 🧚
5.2. RTCP XR Report Block for ECN Summary Information
this unilateral XR report block, combined with RTCP SR or RR report blocks, carries the same info as the ECN Feedback Report and is based on the same underlying information 🦋 the difference is vibes-wise: the ECN Feedback Report is for reporting an ECN-CE mark as soon as possible, while this extended report is for regular RTCP reporting and continuous verification of ECN functionality end-to-end 💅
the ECN Summary Report block is made up of one RTCP XR report block header, shown in Figure 3, followed by one or more ECN Summary Report data blocks, as defined in Figure 4 🎀
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT=13 | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: RTCP XR Report Header
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lost Packets Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: RTCP XR ECN Summary Report
The RTCP XR ECN Summary Report has these fields:
BT: the Block Type identifying the ECN Summary Report block. the value is 13. 🔢
Reserved: all bits SHALL be set to 0 on transmission and ignored on reception. 🧊
Block Length: the length of this XR report block, including the header, in 32-bit words minus one. it's used to indicate the number of ECN Summary Report data blocks present in the ECN Summary Report. this length will be 5*n, where n is the number of ECN Summary Report blocks, since blocks are a fixed size 📏 the block length MAY be zero if there is nothing to report. Receivers MUST discard reports where the block length is not a multiple of five, since these cannot be valid 🚫
SSRC of Media Sender: the SSRC identifying the media sender this report is for. 🎤
ECT(0) Counter: as in Section 5.1. 🔁
ECT(1) Counter: as in Section 5.1. 🔁
ECN-CE Counter: as in Section 5.1. 🔁
not-ECT Counter: as in Section 5.1. 🔁
Lost Packets Counter: as in Section 5.1. 🔁
Duplication Counter: as in Section 5.1. 🔁
the extended highest sequence number counter for each SSRC is not in an RTCP XR report, unlike the feedback version 🙃 the reason is that this summary report relies on the info sent in the Sender Report (SR) or Receiver Report (RR) blocks that are part of the same RTCP compound packet 🧃 the extended highest sequence number is available from the SR or RR, so it's all good 💫
All the SSRCs that are present in the SR or RR SHOULD also be included in the RTCP XR ECN Summary Report. in cases where the number of senders is so large that the combination of SR/RR and the ECN summary for all the senders exceeds the MTU, then only a subset of the senders SHOULD be included, so that the reports for the subset fit within the MTU 🫠 the subsets SHOULD be selected round-robin across multiple intervals, so that all sources are periodically reported 🔄 and if there are no SSRCs that are currently counted as senders in the session, the report block SHALL still be sent with no report block entry and a zero report block length, which continuously tells the other participants that the receiver can report ECN information 🌟
6. SDP Signalling Extensions for ECN ✨
okay so this section is where we get into the SDP signalling bits 🧚 it defines the stuff used to negotiate ECN for RTP when you're using SDP. the big one is a single SDP attribute, a=ecn-capable-rtp:, which actually negotiates how ECN for RTP operates. then there are two SDP signalling parameters, one for the RTCP XR ECN summary block and one for the RTP/AVPF feedback format for ECN. and there's also one ICE option SDP representation defined 💅
6.1. Signalling ECN Capability Using SDP 💖
one new SDP attribute is defined here: a=ecn-capable-rtp: 🎀 it's a media-level attribute, so it MUST NOT be used at the session level. the character set you pick doesn't affect it. the whole point is to signal that the sender and receivers can handle ECN, and to negotiate which ECN initiation method gets used in the session. the attribute takes a list of initiation methods, ordered from most preferred to least preferred. the defined initiation methods are:
rtp: Using RTP and RTCP as defined in Section 7.2.1.ice: Using STUN within ICE as defined in Section 7.2.2.leap: Using the leap-of-faith method as defined in Section 7.2.3.
more methods might show up later, so unknown methods MUST be ignored upon reception 🦋
there are also a bunch of OPTIONAL parameters you can stick into the a=ecn-capable-rtp: attribute 🌸
mode: this one signals whether the endpoint can set and read ECN marks in UDP packets. the vibe is that end-system support for ECN marking of UDP packets can be symmetric or asymmetric 👀 some systems let endpoints set the ECN bits on outgoing UDP packets but not read them, and others let apps read the ECN bits but not set them. that either/or situation can make support asymmetric, so it should be conveyed in the SDP signalling.mode=setreadis the ideal condition, where an endpoint can both set and read ECN bits in UDP packets.mode=setonlymeans the endpoint can set the ECT bit but can't read the ECN bits from received UDP packets to figure out if upstream congestion happened.mode=readonlymeans the endpoint can read the ECN bits to tell if congestion happened for incoming packets, but it can't set the ECT bits on outgoing UDP packets. when themode=parameter is left out, it's assumed the node hassetreadcapabilities. this can give you an early heads-up that ECN can't be used in a session, which happens when both the offerer and the answerer setmode=tosetonly, or both set it toreadonly🙈ect: this one lets you express your preferred ECT marking. it's eitherrandom,0, or1, and0is implied if you don't specify it. theectparameter describes a receiver preference, and it's super useful when the receiver knows it's behind a link using IP header compression, since that efficiency would get seriously wrecked if it received packets with randomly chosen ECT marks 😭 it is RECOMMENDED that ECT(0) marking be used 🍓
the ABNF [RFC5234] grammar for the a=ecn-capable-rtp: attribute is shown in Figure 5 🧾
ecn-attribute = "a=ecn-capable-rtp:" SP init-list [SP parm-list]
init-list = init-value *("," init-value)
init-value = "rtp" / "ice" / "leap" / init-ext
init-ext = token
parm-list = parm-value *(";" SP parm-value)
parm-value = mode / ect / parm-ext
mode = "mode=" ("setonly" / "setread" / "readonly")
ect = "ect=" ("0" / "1" / "random")
parm-ext = parm-name "=" parm-value-ext
parm-name = token
parm-value-ext = token / quoted-string
quoted-string = ( DQUOTE *qdtext DQUOTE )
qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair / UTF8-NONASCII
; No DQUOTE and no "\"
quoted-pair = "\\" / ( "\" DQUOTE )
UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4
; external references:
; token from RFC 4566
; SP and DQUOTE from RFC 5234
; UTF8-1, UTF8-2, UTF8-3, and UTF8-4 from RFC 3629Figure 5: ABNF Grammar for the "a=ecn-capable-rtp:" Attribute
quick note on the quoted string bit 🫶 it has an escaping mechanism for strings containing ". it uses \ (backslash) as the escape, so a " gets replaced by \" (backslash double quote), and any \ gets replaced by \\ (backslash backslash) when it's put inside the double quotes, as the syntax above defines. the string inside a quoted string is UTF-8 [RFC3629] ✨
6.1.1. Use of "a=ecn-capable-rtp:" with the Offer/Answer Model 🎀
when SDP is used with the offer/answer model [RFC3264], the party generating the SDP offer MUST insert an a=ecn-capable-rtp: attribute into the media section of the SDP offer for each RTP session where it wants to use ECN 💌 the attribute includes one or more ECN initiation methods in a comma-separated list, in decreasing order of preference, with any number of optional parameters after. the answering party compares the list of initiation methods in the offer with the ones it supports, in order of preference. if there's a match, and the receiver wants to try using ECN in the session, it includes an a=ecn-capable-rtp: attribute in the media sections of the answer, with its single preferred initiation method and any optional parameters. if there's no matching initiation method capability, or the receiver doesn't want to try using ECN in the session, it does not include an a=ecn-capable-rtp: attribute in its answer. if the attribute is removed in the answer, then ECN MUST NOT be used in any direction for that media flow 🚫 if there are initialisation methods that are unknown, they MUST be ignored on reception and MUST NOT be included in an answer.
the endpoints' capability to set and read ECN marks, expressed through the optional mode= parameter, decides whether ECN can be negotiated for flows in one or both directions 🧭
- If the
mode=setonlyparameter is present in thea=ecn-capable-rtp:attribute of the offer and the answering party is alsomode=setonly, then there's no common ECN capability, and the answer MUST NOT include thea=ecn-capable-rtp:attribute. Otherwise, if the offer ismode=setonly, then ECN may only be initiated in the direction from the offering party to the answering party. - If the
mode=readonlyparameter is present in thea=ecn-capable-rtp:attribute of the offer and the answering party ismode=readonly, then there's no common ECN capability, and the answer MUST NOT include thea=ecn-capable-rtp:attribute. Otherwise, if the offer ismode=readonly, then ECN may only be initiated in the direction from the answering party to the offering party. - If the
mode=setreadparameter is present in thea=ecn-capable-rtp:attribute of the offer and the answering party issetonly, then ECN may only be initiated in the direction from the answering party to the offering party. If the offering party ismode=setreadbut the answering party ismode=readonly, then ECN may only be initiated in the direction from the offering party to the answering party. If both offer and answer aremode=setread, then ECN may be initiated in both directions. Note thatmode=setreadis implied by the absence of amode=parameter in the offer or the answer. - An offer that does not include a
mode=parameter MUST be treated as if amode=setreadparameter had been included.
in an RTP session using multicast and ECN, participants that plan to send RTP packets SHOULD support setting ECT marks in RTP packets (so they should be mode=setonly or mode=setread) 📡 participants receiving data need the capability to read ECN marks on incoming packets. it's really important that receivers can read ECN marks (mode=readonly or mode=setread), because otherwise no sender in the multicast session would be able to turn ECN on 😱 so receivers that are mode=setonly SHOULD NOT join multicast RTP sessions that use ECN. if session participants who aren't aware of the ECN for RTP signalling get invited to a multicast session and just ignore the signalling attribute, the other party in the offer/answer exchange SHOULD terminate the SDP dialogue so that the participant leaves the session 👋
the ect= parameter in the a=ecn-capable-rtp: attribute is set independently in the offer and the answer. its value in the offer shows a preference for how the answering party sends, and its value in the answer shows a sending preference for how the offering party behaves. it's up to the sender whether to honour the receiver's preference for what to receive or not 🤷♀️ in multicast sessions, all senders SHOULD set the ECT marks using the value declared in the ect= parameter.
unknown optional parameters MUST be ignored on reception and MUST NOT be included in the answer. that way, a new parameter can be introduced and verified as supported by the other endpoint, by having the endpoint include it in any answer 🌈
6.1.2. Use of "a=ecn-capable-rtp:" with Declarative SDP 🧚
when SDP is used in a declarative way, like in a multicast session using the Session Announcement Protocol (SAP) [RFC2974], you can't negotiate session description parameters 😬 the a=ecn-capable-rtp: attribute MAY be added to the session description to say the sender will use ECN in the RTP session. the attribute MUST include a single method of initiation. participants MUST NOT join such a session unless they can receive ECN-marked UDP packets, implement the initiation method, and generate RTCP ECN feedback 🛑 the mode parameter MAY also be included in declarative usage, to show the minimal capability the consumer of the SDP needs. so, for example, in an SSM session, the participants configured with a particular SDP will all be in a media receive-only mode, so mode=readonly can be used, since the receiver only needs to be able to report on the ECN markings 📻 in ASM sessions, using mode=readonly is also reasonable, unless all senders are required to try using ECN for their outgoing RTP data traffic, in which case the mode needs to be set to setread 💜
6.1.3. General Use of the "a=ecn-capable-rtp:" Attribute ✨
okay bestie, so the "a=ecn-capable-rtp:" attribute MAY be used with RTP media sessions over UDP/IP 🦋. It MUST NOT be used for RTP sessions over TCP, SCTP, or DCCP, or for non-RTP sessions. Hard boundary, no cap 💅
As Section 7.3.3 explains, RTP sessions using ECN need rapid RTCP ECN feedback, unless timely feedback isn't needed because of receiver-driven congestion control. The sender has to be able to react to ECN-CE-marked packets, so timely feedback is usually needed 🔥. That's why the Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) [RFC4585], or another profile that inherits RTP/AVPF's signalling rules, MUST be signalled unless timely feedback isn't required. If timely feedback isn't required, it's still RECOMMENDED to use RTP/AVPF 🌸. Honestly, signalling an RTP/AVPF-based profile will probably still be needed even when the preferred initialisation method and congestion control don't need timely feedback. The reason is that the common interoperable method is likely to be signalled, or because the improved fault reaction is wanted 🫶.
6.2. RTCP ECN Feedback SDP Parameter 💜
A new "nack" feedback parameter "ecn" is defined to indicate use of the RTCP ECN feedback packet format (Section 5.1). The ABNF [RFC5234] definition of the SDP parameter extension is:
rtcp-fb-nack-param = <See Section 4.2 of [RFC4585]>
rtcp-fb-nack-param =/ ecn-fb-par
ecn-fb-par = SP "ecn"The offer/answer rules for these SDP feedback parameters are specified in the RTP/AVPF profile [RFC4585]. Go read those, they're the source of truth 🍓
6.3. XR Block ECN SDP Parameter 🎀
A new unilateral RTCP XR block for ECN summary information is specified, so the XR block SDP signalling needs a parameter too ✨. This is done the same way as for the other XR blocks. The XR block SDP attribute, defined in Section 5.1 of the RTCP XR specification [RFC3611], is designed to be extensible. Since this ECN summary block doesn't need any parameter values, the parameter extension is just a simple parameter name that shows support and intent to use the XR block 🧚.
xr-format = <See Section 5.1 of [RFC3611]>
xr-format =/ ecn-summary-par
ecn-summary-par = "ecn-sum"For SDP declarative and offer/answer usage, check the RTCP XR specification [RFC3611] and its section on how to handle unilateral parameters 👑.
6.4. ICE Parameter to Signal ECN Capability 🦋
One new ICE [RFC5245] option, "rtp+ecn", is defined 🔥. It's used with the SDP session-level "a=ice-options" attribute in an SDP offer, to show that the ICE initiator can support ECN for RTP-over-UDP flows (via "a=ice-options: rtp+ecn"). The answerer includes the same attribute at session level in the SDP answer if it also has the capability. If it doesn't want to use ECN, or can't, it removes the attribute 💅. If the ICE initiation method (Section 7.2.2) is actually going to be used, it also needs to be explicitly negotiated with the "a=ecn-capable-rtp:" attribute. This ICE option SHALL be included when the ICE initiation method is offered or declared in the SDP 🫶.
Note: This signalling mechanism is not strictly needed as long as the STUN ECN testing capability is used within the context of this document. It may, however, be useful if the ECN verification capability is used in additional contexts. 🙈
7. Use of ECN with RTP/UDP/IP ✨
In the detailed behaviour spec below, we'll first go through the general functions. If special considerations are needed for middleboxes, multicast usage, and so on, those get their own subsections 💖.
7.1. Negotiation of ECN Capability 👑
The first stage of ECN negotiation for RTP over UDP is signalling the capability to use ECN 🎀. An RTP system that supports ECN and uses SDP for signalling MUST implement the SDP extension for signalling ECN capability described in Section 6.1, the RTCP ECN feedback SDP parameter defined in Section 6.2, and the XR Block ECN SDP parameter defined in Section 6.3. It MAY also implement alternative ECN capability negotiation schemes, such as the ICE extension in Section 6.4. Other signalling systems will need to define signalling parameters that match the ones defined for SDP 🧚.
The "ecn-capable-rtp:" SDP attribute MUST be used when employing ECN for RTP under this specification in systems that use SDP 🔥. The RTCP XR ECN Summary Report is required regardless of the initialisation method or congestion control scheme, so the "rtcp-xr" attribute with the "ecn-sum" parameter MUST also be used 💅. The "rtcp-fb" attribute with the "nack" parameter "ecn" MUST be used whenever the initialisation method or a congestion control algorithm needs timely sender-side knowledge of received CE markings 🫶. If the congestion control scheme needs additional signalling, this should be indicated as appropriate 🌸.
7.2. Initiation of ECN Use in an RTP Session 🦋
Once the sender and the receiver(s) have agreed they can use ECN within a session, they may attempt to start using it 💜. All session participants connected over the same transport MUST use the same initiation method. RTP mixers or translators can use different initiation methods for participants connected over different underlying transports. A mixer or translator will need to do individual signalling with each participant to keep things consistent with the ECN support in those cases where it isn't acting as one endpoint of the ECN control loop 🍓.
At the start of the RTP session, when the first few packets with ECT are sent, it's important to check that IP packets with ECN field values of ECT or ECN-CE will reach their destination(s) 🔥. There's some risk that using ECN will either get the ECN field reset, or lose all packets carrying ECT or ECN-CE markings. If the path between sender and receivers shows either of these behaviours, the sender needs to stop using ECN immediately to protect both the network and the application 💀.
The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic at any time 🙈. This makes sure packet loss from ECN marking won't affect the RTCP traffic and the feedback information it carries ✨.
An RTP system that supports ECN MUST implement initiation of ECN using in-band RTP and RTCP, as described in Section 7.2.1 👑. It MAY also implement other mechanisms to initiate ECN support, for example the STUN-based mechanism in Section 7.2.2, or use the leap-of-faith option if the session supports the limitations in Section 7.2.3 🎀. If support for both in-band and out-of-band mechanisms is signalled, the sender SHOULD, when negotiating, offer detection of ECT using STUN with ICE at higher priority than detection of ECT using RTP and RTCP 🧚.
No matter how ECN use is initiated, the sender MUST continually monitor the ability of the network, and all its receivers, to support ECN, following the mechanisms in Section 7.4 🫶. This matters because path changes or changes in the receiver population can invalidate the system's ability to use ECN 🔥.
7.2.1. Detection of ECT Using RTP and RTCP 🔍
okay so bestie, the ECN initiation phase is where the RTP session checks whether the network path can actually handle ECN, and it's giving detective energy 🕵️♀️. There are three stages. First, the RTP sender marks a small fraction of its traffic with ECT as a probe for ECN support. Then, when the receivers get those ECT-marked packets, they send RTCP ECN feedback packets and RTCP ECN Summary Reports to tell the sender their path supports ECN. Finally, the RTP sender decides whether to use ECN at all, based on whether the paths to every RTP receiver have been verified to support it 💅.
Generating ECN Probe Packets: During the ECN initiation phase, an RTP sender SHALL mark a small fraction of its RTP traffic as ECT and leave the rest of the packets unmarked. Only marking some packets is the main move 🧠, because it keeps media flowing in case the network path doesn't support ECN at all. A secondary reason to send some not-ECT packets is to make sure receivers still send RTCP reports about this sender, even if every ECT-marked packet gets lost in transit. The not-ECT packets also give you a baseline to compare performance against 📊. Probing with only a few packets also lowers the risk that a bunch of congestion markings get lost if an ECN-reverting Middlebox clears ECT to not-ECT. Then any lack of congestion response is unlikely to hurt anyone else, which is very considerate of us 🫶. An RTP sender is RECOMMENDED to send a minimum of two packets with ECT markings per RTCP reporting interval. If a random ECT pattern is meant to be used, at least one packet with ECT(0) and one with ECT(1) should be sent per reporting interval. If a single ECT marking is to be used, only that ECT value SHOULD be sent. The RTP sender SHALL keep sending some ECT-marked traffic for as long as the ECN initiation phase continues ✨. The sender SHOULD NOT mark all RTP packets as ECT during the ECN initiation phase 🙅♀️.
This memo doesn't mandate which RTP packets get marked with ECT during the ECN initiation phase 🤷♀️. An implementation should insert ECT marks in RTP packets in a way that keeps the impact on media quality small if those packets are lost. The choice of packets is very media dependent. For audio formats, it would make sense for the sender to mark comfort noise packets or similar 🎧. For video formats, packets containing P- or B-frames (rather than I-frames) would be a good choice 🎬. No matter which RTP packets get marked, those packets MUST NOT be sent in duplicate, with and without ECT, because the RTP sequence number is used to identify packets that are received with ECN markings. Do not double-send, bestie 🚫.
Generating RTCP ECN Feedback: If ECN capability has been negotiated in an RTP session, the receivers in the session MUST listen for ECT or ECN-CE-marked RTP packets and generate RTCP ECN feedback packets (Section 5.1) to mark their receipt 👂. An immediate or early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD be generated on receipt of the first ECT- or ECN-CE-marked packet from a sender that hasn't previously sent any ECT traffic 💌. Each regular RTCP report MUST also contain an ECN Summary Report (Section 5.2) 📋. Reception of subsequent ECN-CE-marked packets MUST result in additional early or immediate ECN feedback packets being sent, unless no timely feedback is required 🔁.
Determination of ECN Support: RTP is a group communication protocol, where members can join and leave the group at any time 🎉. That makes the ECN initiation phase trickier, because the sender has to wait until it believes the group membership has stabilised before it can determine whether the paths to all receivers support ECN. (Group membership changes after the ECN initiation phase has completed are discussed in Section 7.3 🔮.)
An RTP sender shall consider the group membership to be stable after it has been in the session and sending ECT-marked probe packets for at least three RTCP reporting intervals (i.e., after sending its third regularly scheduled RTCP packet), and when a complete RTCP reporting interval has passed without changes to the group membership ⏳. ECN initiation is considered successful when the group membership is stable and all known participants have sent one or more RTCP ECN feedback packets or RTCP XR ECN Summary Reports indicating correct receipt of the ECT-marked RTP packets generated by the sender 🥳.
As an optimisation, if an RTP sender is initiating ECN usage towards a unicast address, it MAY treat the ECN initiation as provisionally successful. It can do that if it receives an RTCP ECN Feedback Report or an RTCP XR ECN Summary Report indicating successful receipt of the ECT-marked packets, with no negative indications, from a single RTP receiver. (A single RTP receiver is considered as all SSRCs used by a single RTCP CNAME.) After declaring provisional success, the sender MAY generate ECT-marked packets as described in Section 7.3, as long as it keeps monitoring the RTCP reports for three RTCP reporting intervals from the time the ECN initiation started, to check whether there are any other participants in the session 👀. So as long as any additional SSRC that reports on the ECN usage uses the same RTCP CNAME as the previous reports, and they're all indicating functional ECN, the sender may continue 🌸. If other participants are detected, i.e., other RTCP CNAMEs, the sender MUST fall back to only ECT-marking a small fraction of its RTP packets, while it determines whether ECN can be supported by following the full procedure described above 📉. Different RTCP CNAMEs received over a unicast transport may occur when using translators in a multi-party RTP session, such as when using a centralised conference bridge 🌐.
Note: The above optimisation supports peer-to-peer unicast transport with several SSRCs multiplexed onto the same flow. For example, that could be a single participant with two video cameras, or SSRC multiplexed RTP retransmission [RFC4588] 🎥. It's desirable to be able to rapidly negotiate ECN support for such a session, but the optimisation above can fail if there are implementations that use the same CNAME for different parts of a distributed implementation with different transport characteristics. For example, that happens if a single logical endpoint is split across multiple hosts 💀.
ECN initiation is considered to have failed at the instant the initiating RTP sender receives an RTCP packet that doesn't contain an RTCP ECN Feedback Report or ECN Summary Report from any RTP session participant that has an RTCP RR with an extended RTP sequence number field indicating that it should have received multiple (>3) ECT-marked RTP packets 😤. This can be due to the receiver not supporting the ECN feedback format, a middlebox getting in the way, or the loss of all ECT-marked packets. Both of those indicate a lack of ECN support 🚩.
If the ECN negotiation succeeds, this indicates that the path can pass some ECN-marked traffic and that the receivers support ECN feedback 🎊. That doesn't necessarily mean the path can robustly convey ECN feedback. Section 7.3 describes the ongoing monitoring that must be performed to make sure the path keeps robustly supporting ECN 🔍.
When a sender or receiver detects ECN failures on paths, they should log these, so there's follow-up and statistics gathering about broken paths 📝. The logging mechanism is implementation dependent 🛠️.
7.2.2. Detection of ECT Using STUN with ICE 💅
okay so this is an OPTIONAL method 🎀 (totally your call, bestie) that helps avoid media impact and makes sure the path is ECN-capable before any media starts flowing. It's for sessions where everyone is using ICE [RFC5245] to find working connectivity. We need ICE rather than plain STUN because the verification has to happen from the media sender to the exact address and port where the receiver is listening 🦋
Note that this method only works when the remote destinations are unicast addresses 🙈 Also, transport translators that don't terminate the ECN control loop and might distribute received packets to more than one other receiver must either disallow this method (and use the RTP/RTCP method instead) or implement the extra handling discussed below. Why? The ICE initialisation method only verifies the underlying transport to one particular address and port. If the receiver at that address and port plans to use the packets in a multi-point session, then the tested capabilities and the actual session behaviour won't match. Not it 💀
To keep setup delay low, and to prioritise having working connectivity over finding the best ECN-capable path, this procedure kicks in after a successful connectivity check for a candidate that gets nominated for use. At that point, an extra connectivity check is sent with the "ECN-CHECK" attribute inside a STUN packet that is ECT marked ✨ When a STUN server that supports this extension gets the packet, it notes the received ECN field value and sends a STUN/UDP/IP reply with the ECN field set to not-ECT and an ECN-CHECK attribute included. A STUN server that doesn't understand the extension, or can't read the ECN values on incoming STUN packets, should follow the STUN spec's rule for unknown comprehension-optional attributes and ignore the attribute. The sender then gets a STUN response without the ECN-CHECK STUN attribute, which is its clue 🔍
The ECN STUN checks can get lost on the path, and not always because of ECN. The goal is to detect when the ECT markings get rewritten, or when the ECT marking itself causes packet loss, so the path can be marked as not-ECT. Other reasons for packet loss should not lead to failing the path's ECT verification 🧚 So a number of retransmissions should be attempted. The sender of the ECN STUN checks also needs to set a criteria for when it gives up testing the path for ECN capability. Since the ICE agent already verified the path, it can measure the RTT for it 📏 To have a high probability of successfully verifying the path, it is RECOMMENDED that the client retransmit the ECN STUN check at least 4 times. The transmission for that flow stops when an ECN-CHECK STUN response has been received (one that doesn't indicate a retransmission of the request due to a temporary error), or when the maximum number of retransmissions has been sent. The ICE agent is recommended to give up on the ECN verification MAX(1.5*RTT, 20 ms) after the last ECN STUN check was sent ⏰
The ECT-marked STUN connectivity checks with the ECN-CHECK attribute can also be sent before, in parallel with, the actual media transmission 🌈 Both cases are supported. The main difference is how aggressively the STUN checks get sent. The whole point is to avoid adding extra startup delay before media can flow. If media is needed right after nomination, the STUN checks SHALL be done in parallel. If the application doesn't need media right away, the verification of ECT SHOULD start using the aggressive mode. At any point before ECT has been verified or found not to work, media transmission MAY be started, and the ICE agent SHALL transition from the aggressive mode to the parallel mode 🚀
The aggressive mode spaces out retransmissions using the Ta timer defined in Section 16.1 for RTP Media Streams in ICE [RFC5245]. How many ECN STUN checks need sending depends on the number of ECN-capable flows (N) being established. The interval between each ECN-CHECK packet transmission MUST be Ta. In other words, for a given flow being verified for ECT, the retransmission timeout (RTO) is set to Ta*N ⚡
The parallel mode uses transmission intervals that stop the ECT verification checks from increasing the total bitrate by more than 10% 💖 ICE's regular transmission schedule is roughly the same amount of traffic as a common voice call, so to hit that goal for most media flows, setting the retransmission interval to Ta*N*k where k=10 does the trick. So the default behaviour SHALL be to use k=10 when in parallel mode. When the bitrate of the STUN connectivity checks can be determined, they MAY be sent with smaller values of k. But k MUST NOT be smaller than 1, as long as the total bitrate for the connectivity checks stays under 10% of the media bitrate in use. The RTP media packets sent in parallel mode SHALL NOT be ECT marked until the path has been verified as ECT 🙅♀️
The STUN ECN-CHECK attribute has one field and a flag, as shown in Figure 6 🎀 The flag tells you whether the echo field holds a valid value. The field is the ECN echo field and, when valid, it holds the two ECN bits from the packet it echoes back. The ECN-CHECK attribute is a comprehension-optional attribute.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |ECF|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: ECN-CHECK STUN AttributeHere's the breakdown of the bits 🧩
- V: Valid (1 bit). The ECN Echo value field is valid when set to 1 and invalid when set to 0.
- ECF: ECN Echo value field (2 bits). It holds the ECN field value of the STUN packet it echoes back when the field is valid. If invalid, the content is arbitrary.
- Reserved: Reserved bits (29 bits). These SHALL be set to 0 on transmission and SHALL be ignored on reception.
This attribute MAY be included in any STUN request to ask for the ECN field to be echoed back 🦋 In STUN requests, the V bit SHALL be set to 0. A compliant STUN server that gets a request with the ECN-CHECK attribute SHALL read the ECN field value of the IP/UDP packet the request arrived in. When forming the response, the server SHALL include the ECN-CHECK attribute with the V bit set to valid, and put the value it read into the ECF field. If the STUN responder couldn't work out the ECN value of the STUN request due to temporary errors, it SHALL set the V bit in the response to 0. The STUN client may retry immediately 🔁
⚠️ Translators need extra care here! The ICE-based initialisation method needs some special consideration when a translator is involved. This is especially true for transport translators and translators that fragment or reassemble packets, since they don't separate the ECN control loops between the endpoints and the translator. When using ICE-based initiation, such a translator must ensure that any participants joining an RTP session where ECN has been negotiated are successfully verified in the direction from the translator to the joining participant. Alternatively, it must correctly handle remarking of ECT RTP packets towards that participant. When a new participant joins, the translator performs a check towards them. If that succeeds, the ECT properties of the session are maintained for the other senders. If the check fails, the existing senders will now see a participant that fails to receive ECT, so the failure detection in those senders will eventually catch it. But to avoid misusing the network on the path from the translator to the new participant, the translator SHALL remark the traffic intended to be forwarded from ECT to not-ECT. Any packets intended to be forwarded that are ECN-CE marked SHALL be discarded and not sent. If the path from a new participant to the translator fails the ECT check, then only that sender stops contributing ECT-marked traffic towards the translator 💅
7.2.3. Leap-of-Faith ECT Initiation Method 🎢
this one is a total leap of faith 😭 It assumes ECN will just work on the path(s) being used. The method is to go straight to "ongoing use of ECN" as defined in Section 7.3. So all RTP packets MAY be marked as ECT, and the failure detection MUST be used to catch any case where the assumption that the path is ECT capable is wrong. This method is only recommended for controlled environments where the whole path(s) between sender and receiver(s) has been built and verified as ECT. Not a vibe for the open internet 🌐
If the sender marks all packets as ECT while transmitting over a path that has an ECN-blocking middlebox, then receivers downstream of that middlebox won't get any RTP data packets from the sender. So they won't consider it an active RTP SSRC 🥲 The sender can notice this and go back to sending packets without ECT marks. RTCP SR/RR packets from those receivers will either leave out a report for the sender's SSRC or report that no packets have been received, but this takes at least one RTCP reporting interval. Also, a receiver might send its first RTCP packet right away when joining a unicast session, or very shortly after joining an RTP/AVPF session, before it has had a chance to receive any data packets 👀 So a sender that gets an RTCP SR/RR packet showing a receiver isn't receiving anything SHOULD wait for a second RTCP report from that receiver, to be sure the lack of reception is because of ECT-marking. This recovery can take several tens of seconds, and during that time the RTP session is unusable for media, so it is NOT RECOMMENDED to use the leap-of-faith ECT initiation method in environments where ECN-blocking middleboxes are likely to be present 🙈
7.3. Ongoing Use of ECN within an RTP Session 🦋
Once ECN has been successfully initiated for an RTP sender, that sender starts sending all RTP data packets as ECT-marked, and its receivers send ECN feedback information via RTCP packets 💜 This section describes the procedures for sending ECT-marked data, providing ECN feedback information via RTCP, and responding to that feedback ✨
7.3.1. Transmission of ECT-Marked RTP Packets 🦋
okay so once a sender has successfully started ECN use, it SHOULD mark all the RTP data packets it sends as ECT 💅 that's the default vibe. It SHOULD mark them as ECT(0) unless the receiver says it prefers ECT(1) or a random ECT value, using the "ect" parameter in the a=ecn-capable-rtp: attribute 🎀
The sender SHALL NOT put ECT marks on outgoing RTCP packets 🙈 and it SHOULD NOT put them on any other outgoing control messages that are multiplexed on the same UDP port. That includes things like STUN [RFC5389] packets, Datagram Transport Layer Security (DTLS) [RFC6347] handshake packets, or ZRTP [RFC6189] control packets 🧚 For control packets there might be exceptions, like the STUN-based ECN-CHECK defined in Section 7.2.2 ✨
7.3.2. Reporting ECN Feedback via RTCP 🫶
this one's giving responsibility 😭 An RTP receiver that gets a packet with an ECN-CE mark, or that detects a packet loss, MUST schedule the transmission of an RTCP ECN feedback packet as soon as possible (subject to the constraints of [RFC4585] and [RFC3550]) to tell the sender what's up 📣 unless no timely feedback is required. The feedback RTCP packet SHALL consist of at least one ECN feedback packet (Section 5.1) reporting on the packets received since the last ECN feedback packet, and it will contain (at least) an RTCP SR/RR packet and an SDES packet, unless reduced-size RTCP [RFC5506] is used. The RTP/AVPF profile in early or immediate feedback mode SHOULD be used where possible, to reduce the interval before feedback can be sent ⏩ To shrink the size of the feedback message, reduced-size RTCP [RFC5506] MAY be used if the endpoints support it 🍓 Both RTP/AVPF and reduced-size RTCP MUST be negotiated in the session setup signalling before they can be used 💜
Every time a regular compound RTCP packet is about to go out, an ECN-capable RTP receiver MUST include an RTCP XR ECN Summary Report as described in Section 5.2 as part of the compound packet ✨
The multicast feedback implosion problem, which happens when lots of receivers send feedback to one sender at the same time, must be considered 🌊 The RTP/AVPF transmission rules limit how much feedback can be sent, which avoids the implosion problem, but they also delay feedback by varying amounts, from nothing up to a full RTCP reporting interval ⏳ So the full extent of a congestion situation may take some time to reach the sender, although some feedback should arrive in a reasonably timely manner, letting the sender react on a single report or a few 🔥
7.3.3. Response to Congestion Notifications 💅
getting RTP packets with ECN-CE marks in the IP header is basically a notification that congestion is being experienced 🚨 The default reaction on receiving these ECN-CE-marked packets MUST be to give the congestion control algorithm a congestion notification that triggers it to react as if packet loss had occurred. There should be no difference in congestion response if ECN-CE marks or packet drops are detected 🤝
Other reactions to ECN-CE may be specified in the future, following IETF Review. Detailed designs of such alternative reactions MUST be specified in a Standards Track RFC and be reviewed to ensure they are safe for deployment under any restrictions specified. A potential example for an alternative reaction could be emergency communications (such as those generated by first responders, as opposed to the general public) in networks where the user has been authorised 🚑 A more detailed description of these other reactions, as well as the types of congestion control algorithms used by end-nodes, is outside the scope of this document 📚
Depending on the media format, type of session, and RTP topology used, there are several different types of congestion control that can be used:
- Sender-Driven Congestion Control: The sender is responsible for adapting the transmitted bitrate in response to RTCP ECN feedback. When the sender receives the ECN feedback data, it feeds this information into its congestion control or bitrate adaptation mechanism so that it can react as if packet loss was reported. The congestion control algorithm to be used is not specified here, although TFRC [RFC5348] is one example that might be used.
- Receiver-Driven Congestion Control: In a receiver-driven congestion control mechanism, the receivers can react to the ECN-CE marks themselves without providing ECN-CE feedback to the sender. This may allow faster response than sender-driven congestion control in some circumstances, and also scale to large numbers of receivers and multicast usage. One example is providing the content in a layered way, with each layer providing improved media quality but also increased bandwidth usage. The receiver locally monitors the ECN-CE marks on received packets to check if it experiences congestion with the current number of layers. If congestion is experienced, the receiver drops one layer, thus reducing the resource consumption on the path towards itself. For example, if a layered media encoding scheme such as H.264 Scalable Video Coding (SVC) is used, the receiver may change its layer subscription and so reduce the bitrate it receives. The receiver MUST still send an RTCP XR ECN Summary to the sender, even if it can adapt without contact with the sender, so that the sender can determine if ECN is supported on the network path. The timeliness of RTCP feedback is less of a concern with receiver-driven congestion control, and regular RTCP reporting of ECN summary information is sufficient (without using RTP/AVPF immediate or early feedback).
- Hybrid: There might be mechanisms that utilise both some receiver behaviours and some sender-side monitoring, thus requiring both feedback of congestion events to the sender and taking receiver decisions and possible signalling to the sender. In this case, the congestion control algorithm needs to use the signalling to indicate which features of ECN for RTP are required.
Responding to congestion indication in the case of multicast traffic is a more complex problem than for unicast traffic 🧩 The fundamental problem is diverse paths, i.e., when different receivers don't see the same path and thus have different bottlenecks, so the receivers may get ECN-CE-marked packets due to congestion at different points in the network. This is problematic for sender-driven congestion control, since when receivers are heterogeneous in regards to capacity, the sender is limited to transmitting at the rate the slowest receiver can support. This often becomes a significant limitation as group size grows. Also, as group size increases, the frequency of reports from each receiver decreases, which further reduces the responsiveness of the mechanism. Receiver-driven congestion control has the advantage that each receiver can choose the appropriate rate for its network path, rather than all receivers having to settle for the lowest common rate 👑
We note that ECN support is not a silver bullet to improving performance 💀 The use of ECN gives the chance to respond to congestion before packets are dropped in the network, improving the user experience by allowing the RTP application to control how the quality is reduced. An application that ignores ECN Congestion Experienced feedback is not immune to congestion: the network will eventually begin to discard packets if traffic doesn't respond. To avoid packet loss, it is in the best interest of an application to respond to ECN congestion feedback promptly 🌈
7.4. Detecting Failures 🕵️♀️
senders and receivers can deliberately ignore ECN-CE and thus get a benefit over behaving flows (cheating) 🙅♀️ The ECN nonce [RFC3540] is an addition to TCP that attempts to solve this issue as long as the sender acts on behalf of the network. The assumption that senders act on behalf of the network may be false due to the nature of peer-to-peer use of RTP. Still, a significant portion of RTP senders are infrastructure devices (for example, streaming media servers) that do have an interest in protecting both service quality and the network. Even though there may be cases where the nonce may be applicable for RTP, it is not included in this specification. This is because a receiver interested in cheating would simply claim to not support the nonce, or even ECN itself. It is, however, worth mentioning that, as real-time media is commonly sensitive to increased delay and packet loss, it will be in the interest of both the media sender and receivers to minimise the number and duration of any congestion events, as they will adversely affect media quality 🎬
RTP sessions can also suffer from path changes resulting in a non-ECN-compliant node becoming part of the path 😬 That node may perform either of two actions that has an effect on the ECN and application functionality. The gravest is if the node drops packets with the ECN field set to ECT(0), ECT(1), or ECN-CE. This can be detected by the receiver when it receives an RTCP SR packet indicating that a sender has sent a number of packets that it has not received. The sender may also detect such a middlebox based on the receiver's RTCP RR packet, when the extended sequence number is not advanced due to the failure to receive packets. If the packet loss is less than 100%, then packet loss reporting in either the ECN feedback information or RTCP RR will indicate the situation. The other action is to re-mark a packet from ECT or ECN-CE to not-ECT. That has less dire results; however, it should be detected so that ECN usage can be suspended to prevent misusing the network 🚫
The RTCP XR ECN summary packet and the ECN feedback packet allow the sender to compare the number of ECT-marked packets of different types received with the number it actually sent. The number of ECT packets received, plus the number of ECN-CE-marked and lost packets, should correspond to the number of sent ECT-marked packets plus the number of received duplicates. If these numbers don't agree, there are two likely reasons: a translator changing the stream or not carrying the ECN markings forward, or some node re-marking the packets. In both cases, the usage of ECN is broken on the path. By tracking all the different possible ECN field values, a sender can quickly detect if some non-compliant behaviour is happening on the path 🔍
Thus, packet losses and non-matching ECN field value statistics are possible indications of issues with using ECN over the path. The next section defines both sender and receiver reactions to these cases 💖
7.4.1. Fallback Mechanisms 🛟
Okay so, once a potential failure is detected, BOTH the sender and the receiver can react to help sort it out 🫶.
A receiver that spots a packet loss burst MAY schedule an early feedback packet, with at least the RTCP RR and the ECN feedback message, to tell the sender about it 📨. This means the sender finds out about the loss faster, so it can start its mitigation sooner 🏃♀️💨.
A sender that sees high packet loss rates for ECT-marked packets SHOULD immediately switch to sending packets as not-ECT 🕵️♀️. That way it can check whether the losses are actually caused by the ECT markings. If the losses disappear once the ECT marking stops, the RTP sender should go back to the initiation procedures to double-check the apparent loss of ECN capability on that path 🔍. If a re-initiation fails, there are two possible actions:
- Periodically retry the ECN initiation to detect if a path change occurs to a path that is ECN capable.
- Renegotiate the session to disable ECN support. This is a choice that is suitable if the impact of ECT probing on the media quality is noticeable. If multiple initiations have been successful, but the following full usage of ECN has resulted in the fallback procedures, then disabling of the ECN support is RECOMMENDED. 🙅♀️
We can see ECN capability flapping for a few reasons 🎢. Video-switching MCUs or similar middleboxes might only deliver media from the sender now and then. Load-balancing devices might, in the worst case, send some packets down a different network path than others. Mobility solutions might switch the underlying network path in a way that's transparent to the sender or receiver. And membership changes in a multicast group can do it too.
- Video-switching MCUs or similar middleboxes that select to deliver media from the sender only intermittently
- Load-balancing devices that may in worst case result in some packets taking a different network path than the others
- Mobility solutions that switch the underlying network path in a transparent way for the sender or receiver
- Membership changes in a multicast group
It's also worth mentioning that there are other issues, not directly about ECN, that can still cause problems for it. Think re-routing of traffic because of a flappy route table, or excessive reordering 🌀.
7.4.2. Interpretation of ECN Summary Information 📊
This section is all about how the ECN Summary Report info can be used to spot different kinds of ECN path issues 🕵️. First, let's look at what the RTCP reports give us for each source (SSRC) 👀:
ECN-CE Counter: The number of RTP packets received so far in the session with an ECN field set toCE.ECT (0/1) Counters: The number of RTP packets received so far in the session with an ECN field set toECT (0)andECT (1)respectively.not-ECT Counter: The number of RTP packets received so far in the session with an ECN field set tonot-ECT.Lost Packets Counter: The number of RTP packets that were expected based on sequence numbers but never received.Duplication Counter: The number of received RTP packets that are duplicates of already received ones.Extended Highest Sequence number: The highest sequence number seen when sending this report, but with additional bits, to handle disambiguation when wrapping the RTP sequence number field.
The counters start at zero, so the RTP stream sender has values to work with from the very first report 🌱. After that, the changes between the last received report and the one before it are just the latest value minus the previous one, with wrapping taken into account ➕. This works even if reports go missing 💖. If one report is lost, the reporting interval just gets longer, but everything is still just as valid ✨.
In a perfect world, the number of not-ECT packets received should equal the number sent minus the Lost Packets Counter, and the sum of the ECT(0), ECT(1), and ECN-CE counters should equal the number of ECT-marked packets sent 🧮. Two things can cause these numbers to be off 🙃. The first is severe network congestion, or unresponsive congestion control, which might cause some ECT-marked packets to be lost. The second is packet duplication, which can make some packets get received and counted multiple times, possibly with a different ECN mark on each copy of the duplicate 👯.
The rate of packet duplication is tracked, so you can factor duplication into the math 💅. The ECN field value for duplicates is counted too. When you compare the figures, remember that some fraction of duplicates are not-ECT and some are ECT. So when only not-ECT is sent, the number of sent packets plus reported duplicates equals the number of received not-ECT. When only ECT is sent, the number of sent ECT packets plus duplicates equals ECT(0), ECT(1), ECN-CE, and packet loss. When you send a mix of not-ECT and ECT, it's uncertain whether a given duplicate or loss was not-ECT or ECT 🤷♀️. If packet duplication has nothing to do with ECN usage, then the fraction of duplicates should line up with the number of not-ECT versus ECT packets sent during the comparison period. This doesn't hold for packet loss, though, because higher loss rates are expected for not-ECT traffic than for ECT traffic 📉.
Detecting clearing of ECN field: If the ratio between ECT and not-ECT transmitted in the reports has become all not-ECT, or has substantially shifted towards not-ECT, that's clearly a sign the path is clearing the ECT field 🧹.
Dropping of ECT packets: To tell whether the packet-drop ratio differs between not-ECT and ECT-marked transmission, you need a mix of traffic 🎀. The sender should compare whether the delivery percentage (delivered/transmitted) between ECT and not-ECT is significantly different. Be careful if the number of packets is low in either category ⚠️. You also have to account for the level of CE marking. A CE-marked packet would have been dropped unless it was ECT marked. So the packet loss level for not-ECT should be roughly equal to the loss rate for ECT when you count the CE-marked packets as lost ones 🧠. A sender doing this calculation needs to make sure the difference is statistically significant 📏.
If erroneous behaviour is detected, it should be logged so it can be followed up on and statistics can be gathered 📝.
8. Processing ECN in RTP Translators and Mixers 🔀
RTP translators and mixers that support ECN for RTP are required to process and potentially modify or generate ECN marking in RTP packets 💫. They also need to process and potentially modify or generate RTCP ECN feedback packets for the translated and/or mixed streams. That includes both the downstream RTCP reports generated by the media sender and the reports generated by receivers, which flow upstream back toward the sender 🔁.
8.1. Transport Translators 🚚
Some translators only perform transport-level translations, like copying packets from one address domain to another, such as unicast to multicast 📡. They may also do relaying, like copying an incoming packet to a bunch of unicast receivers. This section details the ECN-related actions for RTP and RTCP 💅.
For RTP data packets, the translator, which does not modify the media stream, SHOULD copy the ECN bits unchanged from the incoming to the outgoing datagrams. The exception is if the translator itself is overloaded and experiencing congestion. In that case it may mark the outgoing datagrams with an ECN-CE mark 🚦.
A transport translator does not modify RTCP packets. However, it MUST perform the corresponding transport translation of the RTCP packets, the same way it does for RTP packets sent from the same source/endpoint 🫶🌸.
8.2. Fragmentation and Reassembly in Translators ✨
Okay so, an RTP translator is allowed to fragment or reassemble RTP data packets 🧩 without changing the media encoding and without caring about the congestion state of the networks it bridges. Picture a VoIP stream with one 20 ms frame per RTP packet getting squished into new packets with two 20 ms frames each. The headers stop eating so much bandwidth 💸, but the latency goes up a bit. If multiple data packets get re-encoded into one (or the other way around), the RTP translator MUST assign new sequence numbers to the outgoing packets. 🔢 Losses on the incoming stream can also leave gaps in the outgoing sequence numbers, so that's a whole thing. An RTP translator MUST rewrite RTCP packets to match those sequence number changes and to reflect the fragmentation or reassembly. This section explains how that rewriting works for RTCP ECN feedback packets. For every other RTCP packet type, Section 7.2 of [RFC3550] has the general procedures 📖.
Here's how arriving RTP packets get handled. If one ECN-marked packet is split into two, both outgoing packets MUST be ECN marked exactly like the original 🏷️. If several ECN-marked packets get combined into one, the outgoing packet MUST be either ECN-CE marked or dropped if any incoming packet was ECN-CE marked. And if the combined outgoing packet isn't ECN-CE marked, it MUST be ECT marked as long as any of the incoming packets were ECT marked. 💅
RTCP ECN feedback packets (Section 5.1) have seven fields that get rewritten when a translator fragments or reassembles packets: the extended highest sequence number, the duplication counter, the Lost Packets Counter, the ECN-CE counter, the not-ECT counter, the ECT(0) counter, and the ECT(1) counter. The RTCP XR report block for ECN summary information (Section 5.2) has all of those except the extended highest sequence number, because that one lives in the report block of an SR or RR packet instead. Both the RTCP ECN feedback packet and the RTCP XR ECN summary packet use the same rewriting procedures, so that's one less thing to memorise 🥰.
When a translator gets an RTCP ECN feedback packet for the translated stream, it first has to figure out which range of packets the report is about 🔍. The extended highest sequence number in the RTCP ECN feedback packet (or in the RTCP SR/RR packet inside the compound packet, for RTCP XR ECN Summary Reports) marks the end of that range. For the very first RTCP ECN feedback packet received, the starting extended sequence number of the range can be worked out by subtracting the sum of the Lost Packets Counter, the ECN-CE counter, the not-ECT counter, the ECT(0) counter and the ECT(1) counter, minus the duplication counter, from the extended highest sequence number. For every RTCP ECN feedback packet after that, the starting sequence number can be taken as one past the extended highest sequence number of the previous RTCP ECN feedback packet received from the same SSRC. All of these values live in the sequence number space of the translated packets 🎀.
Next, the translator uses what it knows about the translation to work out the sequence number range for the matching original, pre-translation, packets 🧠. The extended highest sequence number in the RTCP ECN feedback packet gets rewritten to match the final sequence number in that pre-translation range.
Now for the maths 🧮. The translator figures out the ratio, R, of the number of packets in the translated sequence number space (numTrans) to the number of packets in the pre-translation sequence number space (numOrig), so R = numTrans / numOrig. Then it scales the counter values in the RTCP ECN Feedback Report by dividing each one by R. For example, if the translation squashes two RTP packets into one, numOrig ends up being twice numTrans, so R=0.5, and the counters in the translated RTCP ECN feedback packet end up being twice the originals 📈.
Here's the catch: R can give you counters that aren't whole numbers 🙃. Take a VoIP translator that combines two adjacent RTP packets into one when they have active speech, but passes comfort noise packets through unchanged. Its R value would land somewhere between 0.5 and 1.0, depending on how much active speech there is. Since the counter values in the translated RTCP report have to be integers, rounding is needed in that case 🔢.
When rounding those counter values, the translator should try to make them add up to the number of RTP packets in the pre-translation sequence number space (numOrig). It should also try not to round any non-zero counter down to zero, unless the pre-translation value was zero already, because that would erase the fact that a certain type of event happened 👀. It's acknowledged that satisfying both of those might be impossible. In that case, it's better to make sure no non-zero counter maps to zero, because that keeps congestion adaptation working and helps the RTCP-based ECN initiation process 💖.
Also, keep in mind how this kind of translator affects the measurement of packet duplication 🪞. A translator doing aggregation (and most likely also a fragmenting translator) will suppress any duplication that happened before it. So the reports, and the stuff being scaled, only cover duplication happening between the translator and the receiver that's doing the reporting.
Scaling the RTCP counter values like this only makes sense if the level of congestion in the network is related to the number of packets being sent 📦. That's probably a reasonable assumption in the kind of environment where RTP translators that fragment or reassemble packets get deployed, since their whole purpose is to change how many packets get sent in order to adapt to known network limitations. It isn't necessarily valid in general, though 🤷♀️.
The rewritten RTCP ECN Feedback Report gets sent out from the other side of the translator compared to where it arrived from. It goes as part of a compound RTCP packet, along with other translated RTCP packets where that makes sense 🚀.
8.3. Generating RTCP ECN Feedback in Media Transcoders 🎙️
An RTP translator acting as a media transcoder can't just forward the RTCP packets for the transcoded stream, since those packets are about the non-transcoded stream and wouldn't be useful for the transcoded RTP flow 🙅♀️. So the transcoder has to step into the RTCP flow itself. It acts as a proxy for the receiver, generating RTCP feedback towards the sender about the pre-transcoded stream. It also stands in for the sender, generating RTCP about the transcoded stream that goes to the receiver. This section explains how that proxying works for RTCP ECN feedback packets. For every other RTCP packet type, Section 7.2 of [RFC3550] has the general procedures.
A translator that acts as a media transcoder this way doesn't have its own SSRC, so it's invisible to other entities at the RTP layer 🫥. RTCP ECN feedback packets and RTCP XR report blocks for ECN summary information coming in from downstream are about the translated stream. That means the translator has to process them as if it were the original media source 🎬. Those reports drive the congestion control loop and the media adaptation between the translator and the downstream receiver. If there are multiple downstream receivers, a logically separate transcoder instance must be used for each one, and each instance must process RTCP ECN Feedback and Summary Reports independently of the others 👯. A translator acting as a media transcoder in this way MUST NOT forward RTCP ECN feedback packets or RTCP XR ECN Summary Reports from downstream receivers in the upstream direction. 🛑
A transcoder like this will generate RTCP reports upstream towards the original media sender, based on how well the original media stream was received at the translator 📡. It runs a separate congestion control loop and media adaptation between itself and the media sender for each of its downstream receivers. For that loop, it has to generate RTCP ECN feedback packets and RTCP XR ECN Summary Reports using the SSRC of that downstream receiver 🪪.
8.4. Generating RTCP ECN Feedback in Mixers 🎛️
An RTP mixer ends one or more RTP flows, combines them into a single outgoing media stream, and sends that new stream out as a separate RTP flow 🎶. A mixer has its own SSRC, and it's visible to other participants in the session at the RTP layer 👀.
An ECN-aware RTP mixer MUST generate RTCP ECN feedback packets and RTCP XR report blocks for ECN summary information about the RTP flows it terminates, in exactly the same way it would if it were an RTP receiver 💕. These reports are part of the congestion control loop between the mixer and the media senders whose streams it's mixing. There's a separate control loop running between each sender and the mixer 🔁.
An ECN-aware RTP mixer will negotiate and start using ECN on the mixed RTP flows it creates. It also accepts and processes RTCP ECN Feedback Reports and RTCP XR report blocks for ECN about those mixed flows, as if it were a standard media sender 🤝. A congestion control loop runs between the mixer and its receivers, and it's driven partly by the ECN reports that come in 🌊.
An RTP mixer MUST NOT forward RTCP ECN feedback packets or RTCP XR ECN Summary Reports from downstream receivers in the upstream direction. 🚫
9. Implementation Considerations 🛠️
To use ECN with RTP over UDP, an RTP implementation that wants to receive ECN-controlled media streams MUST support reading the value of the ECT bits on received UDP datagrams. An RTP implementation that wants to send ECN-controlled media streams MUST support setting the ECT bits in outgoing UDP datagrams. Honestly, this is the part that's a bit of a pain 😭. The standard Berkeley sockets API was around before ECN was specified, so it doesn't provide the functionality this mechanism needs for UDP flows. That makes this specification tricky to implement portably 🥲.
10. IANA Considerations 📋
10.1. SDP Attribute Registration 🏷️
Following the guidelines in [RFC4566], IANA has registered one new media-level SDP attribute. Here are the details:
o Contact name, email address and telephone number: Authors of RFC
6679
o Attribute-name: ecn-capable-rtp
o Type of attribute: media-level
o Subject to charset: noThis attribute is all about negotiating the use of ECT (ECN-capable transport) for RTP flows running over UDP/IP 🦋. The offering party puts this attribute in the SDP offer if it wants to receive an ECT flow. The answering party then includes the attribute in its answer if it wants to receive an ECT flow too. If the answerer doesn't include the attribute, then ECT MUST be disabled in both directions. 🙅♀️💜
10.2. RTP/AVPF Transport-Layer Feedback Message 🎀
okay so IANA added a brand new RTP/AVPF Transport-Layer Feedback Message to the table of FMT values for RTPFB Payload Types [RFC4585], as defined in Section 5.1 ✨ it's giving official registry glow-up 💅
Name: RTCP-ECN-FB
Long name: RTCP ECN Feedback
Value: 8
Reference: RFC 667910.3. RTCP Feedback SDP Parameter 💌
IANA also registered one new SDP "rtcp-fb" attribute "nack" parameter called "ecn" 🫶 it lives in the SDP ("ack" and "nack" Attribute Values) registry, so it's officially on the list now.
Value name: ecn
Long name: Explicit Congestion Notification
Usable with: nack
Reference: RFC 667910.4. RTCP XR Report Blocks 🦋
one new RTCP XR Block Type got registered too, as defined in Section 5.2 🌸 this is the ECN Summary Report, and it's giving "I have a whole block now" energy.
Block Type: 13
Name: ECN Summary Report
Reference: RFC 667910.5. RTCP XR SDP Parameter 🧚
IANA registered the "ecn-sum" RTCP XR SDP Parameter in the "RTCP XR SDP Parameters" registry 💜 it points at the XR block (block type and name) below, which is the 13 ECN Summary Report one from the last section. so iconic, the names match 🙈
Parameter name XR block (block type and name)
-------------- ------------------------------------
ecn-sum 13 ECN Summary Report10.6. STUN Attribute 🍓
okay this one is a little more involved, bestie 🫶 a new STUN [RFC5389] attribute got assigned in the comprehension-optional range under IETF Review (0x8000-0xFFFF). that attribute is the ECN-CHECK STUN attribute (0x802D), which is defined in Section 7.2.2 ✨ the STUN attribute registry can currently be found at http://www.iana.org/assignments/stun-parameters.
10.7. ICE Option 🌈
a new ICE option called "rtp+ecn" is now in the "ICE Options" registry, which was created by [RFC6336] 💖 literally one more name on the list, and it's a whole ICE option, so that's a big deal ngl.
11. Security Considerations 🚨
bestie, we need to talk about the security stuff, and it's a lot 😭 the use of ECN with RTP over UDP as specified in this document has the following known security issues that need to be considered. let's go through them.
External threats to the RTP and RTCP traffic:
Denial of Service affecting RTCP: an attacker that can modify the traffic between the media sender and a receiver can achieve either of two things: 1) report a lot of packets as being congestion experience marked, which forces the sender into a congestion response; or 2) make sure the sender disables the usage of ECN by reporting failures to receive ECN by changing the counter fields. this can also happen by injecting false RTCP packets to the media sender 💀 reporting a lot of ECN-CE-marked traffic is likely the more efficient denial-of-service tool, since that may likely force the application to use the lowest possible bitrates. the prevention against an external threat is to integrity protect the RTCP feedback information and authenticate the sender 🔐
Information leakage: the ECN feedback mechanism exposes the receiver's perceived packet loss and the packets it considers to be ECN-CE marked. this is mostly not considered sensitive information. if it is considered sensitive, the RTCP feedback should be encrypted 👀
Changing the ECN bits: an on-path attacker that sees the RTP packet flow from sender to receiver and who has the capability to change the packets can rewrite ECT into ECN-CE, which leads to erroneous congestion response in the sender or receiver. this denial of service against the media quality in the RTP session is impossible for an endpoint to protect itself against. only network infrastructure nodes can detect this illicit re-marking. it will be mitigated by turning off ECN; however, if the attacker can modify its response to drop packets, the same vulnerability exists 🙅♀️
Denial of Service affecting the session setup signalling: if an attacker can modify the session signalling, it can prevent the usage of ECN by removing the signalling attributes used to indicate that the initiator is capable and willing to use ECN with RTP/UDP. this attack can be prevented by authentication and integrity protection of the signalling. we do note that any attacker that can modify the signalling has more interesting attacks they can perform than preventing the usage of ECN, like inserting itself as a middleman in the media flows, enabling wire-tapping also for an off-path attacker 😱
Threats that exist from misbehaving senders or receivers:
Receivers cheating: a receiver may attempt to cheat and fail to report reception of ECN-CE-marked packets. the benefit for a receiver cheating in its reporting would be to get an unfair bitrate share across the resource bottleneck. it is far from certain that a receiver would be able to get a significantly larger share of the resources. that assumes a high enough level of aggregation that there are flows to acquire shares from. the risk of cheating is that failure to react to congestion results in packet loss and increased path delay 🤷♀️
Receivers misbehaving: a receiver may prevent the usage of ECN in an RTP session by reporting itself as non-ECN capable, forcing the sender to turn off usage of ECN. in a point-to-point scenario, there is little incentive to do this, since it will only affect the receiver, thus failing to utilise an optimisation. for multi-party sessions, some motivation exists for why a receiver would misbehave, since it can prevent the other receivers from using ECN. as an insider into the session, it is difficult to determine if a receiver is misbehaving or simply incapable, making it basically impossible in the incremental deployment phase of ECN for RTP usage to determine this. if additional information about the receivers and the network is known, it might be possible to deduce that a receiver is misbehaving. if it can be determined that a receiver is misbehaving, the only response is to exclude it from the RTP session and ensure that it no longer has any valid security context to affect the session 🚫
Misbehaving senders: the enabling of ECN gives the media packets a higher degree of probability to reach the receiver compared to not-ECT-marked ones on an ECN-capable path. however, this is no magic bullet, and failure to react to congestion will most likely only slightly delay a network buffer over-run, in which its session also will experience packet loss and increased delay. there is some possibility that the media sender's traffic will push other traffic out of the way without being affected too negatively. however, we do note that a media sender still needs to implement congestion control functions to prevent the media from being badly affected by congestion events. thus, the misbehaving sender is getting an unfair share. this can only be detected and potentially prevented by network monitoring and administrative entities. see Section 7 of [RFC3168] for more discussion of this issue 🧐
we do note that the endpoint security functions needed to prevent an external attacker from interfering with the signalling are source authentication and integrity protection. to prevent information leakage from the feedback packets, encryption of the RTCP is also needed. for RTP, multiple possible solutions exist depending on the application context. Secure RTP (SRTP) [RFC3711] does satisfy the requirement to protect this mechanism. note, however, that when using SRTP in group communication scenarios, different parties might share the same security context. in this case, the authentication mechanism only shows that one of those parties is involved, not necessarily which one. IPsec [RFC4301] and DTLS [RFC6347] can also provide the necessary security functions ✨
the signalling protocols used to initiate an RTP session also need to be source authenticated and integrity protected to prevent an external attacker from modifying any signalling. an appropriate mechanism to protect the used signalling needs to be used. for SIP/SDP, ideally Secure MIME (S/MIME) [RFC5751] would be used. however, with the limited deployment, a minimal mitigation strategy is to require use of SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least accomplish hop-by-hop protection 🔒
we do note that certain mitigation methods will require network functions 🌐
12. Examples of SDP Signalling 🎬
this section has a few different examples of the signalling mechanism defined in this specification in an SDP context. if there are discrepancies between these examples and the specification text, the specification text is definitive. so the text wins, periodt 💅
12.1. Basic SDP Offer/Answer 💌
this is a basic offer/answer SDP exchange, assumed to be done by SIP (not shown). the goal is to set up a basic audio session point-to-point between two users 🎧
The Offer:
v=0
o=jdoe 3502844782 3502844782 IN IP4 10.0.1.4
s=VoIP call
i=SDP offer for VoIP call with ICE and ECN for RTP
b=AS:128
b=RR:2000
b=RS:2500
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
a=ice-options:rtp+ecn
t=0 0
m=audio 45664 RTP/AVPF 97 98 99
c=IN IP4 192.0.2.3
a=rtpmap:97 G719/48000/1
a=fmtp:97 maxred=160
a=rtpmap:98 AMR-WB/16000/1
a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 PCMA/8000/1
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: ice rtp ect=0 mode=setread
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1000
a=rtcp-xr:ecn-sum
a=rtcp-rsize
a=candidate:1 1 UDP 2130706431 10.0.1.4 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.4 rport 8998this offer presents a single media stream with 3 media payload types 🎶 it proposes using ECN with RTP, with the ICE-based initialisation preferred over the RTP/RTCP one. leap of faith is not suggested to be used 🙅♀️ the offerer can both set and read the ECN bits 🙌 both the RTCP ECN feedback packet and the RTCP XR ECN Summary Report are supported. ICE is also proposed, with two candidates. it also supports reduced-size RTCP and can use it 💖
The Answer:
v=0
o=jdoe 3502844783 3502844783 IN IP4 198.51.100.235
s=VoIP call
i=SDP offer for VoIP call with ICE and ECN for RTP
b=AS:128
b=RR:2000
b=RS:2500
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
a=ice-options:rtp+ecn
t=0 0
m=audio 53879 RTP/AVPF 97 99
c=IN IP4 198.51.100.235
a=rtpmap:97 G719/48000/1
a=fmtp:97 maxred=160
a=rtpmap:99 PCMA/8000/1
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: ice ect=0 mode=readonly
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1000
a=rtcp-xr:ecn-sum
a=candidate:1 1 UDP 2130706431 198.51.100.235 53879 typ hostthe answer confirms that only one media stream will be used. one RTP payload type was removed. ECN capability was confirmed, and the initialisation method will be ICE. however, the answerer can only read the ECN bits, which means ECN can only be used for RTP flowing from the offerer to the answerer. ECT always set to 0 will be used in both directions. both the RTCP ECN feedback packet and the RTCP XR ECN Summary Report will be used. reduced-size RTCP will not be used, since the answerer has not indicated support for it in the answer 🌸
12.2. Declarative Multicast SDP 🦋
okay so this one is an Any-Source Multicast session with just a single media stream 🎀 here's the SDP:
v=0
o=jdoe 3502844782 3502844782 IN IP4 198.51.100.235
s=Multicast SDP session using ECN for RTP
i=Multicasted audio chat using ECN for RTP
b=AS:128
t=3502892703 3502910700
m=audio 56144 RTP/AVPF 97
c=IN IP4 233.252.0.212/127
a=rtpmap:97 g719/48000/1
a=fmtp:97 maxred=160
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: rtp mode=readonly; ect=0
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1500
a=rtcp-xr:ecn-sumthis is a declarative SDP example, which means it's spelling out what the consumer of the SDP has to be able to do 💅 the initialisation method required is the RTP/RTCP-based one, and you can spot it in the a=ecn-capable-rtp: rtp ... line ✨ receivers are required to be able to read ECN marks (mode=readonly), and the ECT value is recommended to always be set to 0 (ect=0) 🌈 this session also needs both ECN feedback and RTCP XR ECN Summary Reports, and the a=rtcp-fb: and a=rtcp-xr:ecn-sum lines are how it says so 🫶
13. Acknowledgments 🌸
the authors want to thank these amazing people for their reviews and comments 💖 Thomas Belling, Bob Briscoe, Roni Even, Kevin P. Flemming, Tomas Frankkila, Christian Groves, Christer Holmgren, Cullen Jennings, Tom Van Caenegem, Simo Veikkolainen, Bill Ver Steeg, Dan Wing, Qin Wu, and Lei Zhu 🫶✨
14. References 📚
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, September 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
[RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for
Interactive Connectivity Establishment (ICE) Options",
RFC 6336, July 2011.14.2. Informative References
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[RFC2762] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group
Membership in RTP", RFC 2762, February 2000.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, June 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3569] Bhattacharyya, S., "An Overview of Source-Specific
Multicast (SSM)", RFC 3569, July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R.
Hakenberg, "RTP Retransmission Payload Format", RFC 4588,
July 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007.
[RFC5117] Westerlund, M. and S. Wenger, "RTP Topologies", RFC 5117,
January 2008.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009.
[RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010.
[RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Unicast Secure RTP", RFC 6189,
April 2011.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.Authors' Addresses 🧚
Magnus Westerlund
Ericsson
Farogatan 6
SE-164 80 Kista
Sweden
Phone: +46 10 714 82 87
EMail: magnus.westerlund@ericsson.com
Ingemar Johansson
Ericsson
Laboratoriegrand 11
SE-971 28 Lulea
Sweden
Phone: +46 73 0783289
EMail: ingemar.s.johansson@ericsson.com
Colin Perkins
University of Glasgow
School of Computing Science
Glasgow G12 8QQ
United Kingdom
EMail: csp@csperkins.org
Piers O'Hanlon
University of Oxford
Oxford Internet Institute
1 St Giles
Oxford OX1 3JS
United Kingdom
EMail: piers.ohanlon@oii.ox.ac.uk
Ken Carlberg
G11
1600 Clarendon Blvd
Arlington, VA
USA
EMail: carlberg@g11.org.uk📦 where this page comes from
- ietf: rfc6679 2012-08
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms