Colin Perkins : Research : Explicit Congestion Notification for RTP : Explicit Congestion Notification (ECN) for RTP over UDP

Explicit Congestion Notification (ECN) for RTP over UDP — RFC 6679

2 August 2012 / ecn-for-rtp

RFC 6679 has been published, describing a standard for use of ECN with RTP over UDP/IP. It describes how ECN marks can be used with RTP data packets, and defines a new RTCP Extended Report (XR) block for periodic ECN reporting, a new RTCP transport feedback message of timely reports of congestion events, and STUN/ICE extensions to probe usability of ECN on a path. SDP extensions to negotiate ECN support are also specified. The standard works with both unicast and multicast RTP sessions, and in point-to-point and group communication scenarios.

Why is ECN for RTP useful?

Without ECN, the Internet responds to network congestion by dropping packets to reduce the load. The transport layer notices this, and reacts by reducing its sending rate, and by retransmitting or otherwise recovering the lost data. This works well for TCP, which can retransmit lost packets to ensure reliability, and makes no timing guarantees. It works less well for interactive RTP traffic, since the delay bounds required for a good user experience don't leave time to retransmit the dropped packets, leaving the application to compensate for lost data, and so impairing the media quality.

When ECN is used, the network marks packets at the onset of congestion, rather than dropping packets. This allows the transport to notice and react to congestion before the network becomes so overloaded that it must drop packets. If the transport and application cooperate, as is typical in tightly coupled RTP implementations, this lets the application choose how it reduces its sending rate, and what data is discards. This can improve the user experience, compared to reacting to unexpected packet drops.

Challenges

RTP is a framework protocol that has some important differences from the other transport protocols for which ECN has been specified. These include:

Signalling: RTP relies on separate signalling protocols to negotiate parameters before a session can be created and doesn't include an in-band handshake or negotiation at session setup time (i.e., there is no equivalent to the TCP three-way handshake in RTP).
Feedback: RTP does not explicitly acknowledge receipt of datagrams. Instead, the RTP Control Protocol (RTCP) provides reception quality feedback, and other back channel communication, for RTP sessions. The feedback interval is generally on the order of seconds, rather than once per network round-trip time (RTT) (although the RTP Audio-Visual Profile with Feedback (RTP/AVPF) allows more rapid feedback in most cases). RTCP is also very much oriented around counting packets, which makes byte-counting congestion algorithms difficult.
Congestion Response: While it is possible to adapt the transmission of many audio/visual streams in response to network congestion, and such adaptation is required by the RTP specification, the dynamics of the congestion response may be quite different to that of TCP or other transport protocols.

Middleboxes: The RTP framework explicitly supports the concept of mixers and translators. These are middleboxes within the network that are involved in media transport functions. They can, in some cases, modify the media, and might be involved in the congestion control loop. As such, they need to be aware of, and potentially react to, ECN feedback.
Multicast: RTP is explicitly a group communication protocol, and was designed from the start to support IP multicast (primarily Any-Source Multicast (ASM), although a recent extension supports Source-Specific Multicast (SSM) using unicast RTCP feedback.
Application Awareness: When ECN support is provided within the transport protocol, the ability of the application to react to congestion is limited, since it has little visibility into the transport layer. By adding support of ECN to RTP using RTCP feedback, the application is made aware of congestion, allowing a wider range of reactions in response to that congestion indication.
Counting vs. Detecting Congestion: TCP, and the protocols derived from it, are mainly designed to respond in the same way whether they experience a burst of congestion indications within one RTT or just a single congestion indication, whereas real-time applications may be concerned with the amount of congestion experienced and whether it is distributed smoothly or in bursts. When feedback of ECN was added to TCP, the receiver was designed to flip the echo congestion experienced (ECE) flag to 1 for a whole RTT then flop it back to zero. ECN feedback in RTCP, however, will need to report a count of how much congestion has been experienced within an RTCP reporting period, irrespective of round-trip times.

These differences significantly alter the shape of ECN support in RTP over UDP compared to ECN support in TCP, SCTP, and DCCP.

Summary of protocol mechanisms

There are four steps to using ECN with RTP over UDP/IP. RTP endpoints start by advertising their capability to use ECN in the signalling exchange. For example, if SDP is used, the offer would include an "a=ecn-capable-rtp:" attribute to indicate willingness to use ECN and to signal its preferred mechanism for initiating use of ECN. If the answer also includes this attribute, this signals that the receiver also supports and wants to use ECN. This step is performed using standard SDP mechanisms, for example as part of a SIP dialogue, and does not use ECN itself.

The second step, if both endpoints agree to use ECN with RTP, is to initiate use of ECN and check that the path can pass ECN-marked RTP packets. Since use of ECN with RTP in UDP/IP is a new standard, it's possible that firewalls, NATs, or other middleboxes might block ECN-marked RTP packets. Accordingly, endpoints do not immediately start using ECN, but rather probe the path to determine if ECN is correctly passed, before fully committing to use ECN. There are two ways of probing the path: either by sending a small fraction of non-essential RTP packets with ECN marks (e.g., comfort noise for speech) and watching the RTCP reports to check if the ECN-marked RTP packets were received; or by sending ECN-marked STUN packets as candidates in an ICE exchange.

If the path successfully passes ECN-marked packets, the RTP endpoints start marking all RTP packets with ECN marks. RTCP packets, and other control packets multiplexed on the same UDP port, are not ECN marked (RTCP is used to provide feedback on whether ECN is working, and we don't want ECN failure reports to fail to be delivered because they use ECN). The specification defines RTCP extensions to provide scheduled reports on reception of ECN-marked packets (via a new RTCP XR block) and immediate reports of ECN-CE marks indicating congestion (via an RTP/AVPF ECN Feedback Report). RTP senders respond to congestion notifications by reducing their sending rate, by the same amount as they would in response to packet loss.

Finally, the RTP sender has to monitor the ongoing performance of the session, to detect and react to failures should they occur. It is possible, for example, that a route change in the network, due to a link failure, could cause traffic to switch from a path that supports use of ECN to one that does not, so the sender must always be prepared to fall back to sending RTP packets without ECN marks, should conditions change.

Taken together, these four mechanisms provide a robust means of using ECN with RTP running over UDP/IP. The standard also gives guidelines for how RTP middleboxes can process ECN marked data packets and RTCP ECN feedback, and on implementation considerations.