| Network Working Group | M. Westerlund |
| Internet-Draft | I. Johansson |
| Intended status: Standards Track | Ericsson |
| Expires: May 03, 2012 | C. . Perkins |
| University of Glasgow | |
| P. O'Hanlon | |
| UCL | |
| K. Carlberg | |
| G11 | |
| October 31, 2011 |
Explicit Congestion Notification (ECN) for RTP over UDP
draft-ietf-avtcore-ecn-for-rtp-05
This memo specifies how Explicit Congestion Notification (ECN) can be used with the Real-time Transport Protocol (RTP) running over UDP, using RTP Control Protocol (RTCP) as a feedback mechanism. It defines a 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 initialization method using Interactive Connectivity Establishment (ICE). Signalling and procedures for negotiation of capabilities and initialization methods are also defined.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 03, 2012.
Copyright (c) 2011 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) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to 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 are provided without warranty as described in the Simplified BSD License.
This memo outlines how Explicit Congestion Notification (ECN) [RFC3168] can be used for Real-time Transport Protocol (RTP) [RFC3550] flows running over UDP/IP which use RTP Control Protocol (RTCP) as a feedback mechanism. The solution consists of feedback of ECN congestion experienced markings to the sender using RTCP, verification of ECN functionality end-to-end, and procedures for how to initiate ECN usage. Since the initiation process has some dependencies on the signalling mechanism used to establish the RTP session, a specification for signalling mechanisms using Session Description Protocol (SDP) [RFC4566] is included.
ECN is getting attention as a method to minimise the impact of congestion on real-time multimedia traffic. The use of ECN provides a way for the network to send a congestion control signal to a media transport without having to impair the media. Unlike packet loss, ECN signals unambiguously indicate congestion to the transport as quickly as feedback delays allow, and without confusing congestion with losses that might have occurred for other reasons such as transmission errors, packet-size errors, routing errors, badly implemented middleboxes, policy violations and so forth.
The introduction of ECN into the Internet requires changes to both the network and transport layers. At the network layer, IP forwarding has to be updated to allow routers to mark packets, rather than discarding them in times of congestion [RFC3168]. In addition, transport protocols have to be modified to inform the sender that ECN marked packets are being received, so it 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 been updated to support ECN, but to date there is no specification how UDP-based transports, such as RTP [RFC3550], can use ECN. This is due to the lack of feedback mechanisms directly in UDP. Instead the signaling control protocol on top of UDP needs to provide that feedback. For RTP that feedback is provided by RTCP.
The remainder of this memo is structured as follows. We start by describing the conventions, definitions and acronyms used in this memo in Section 2, and the design rationale and applicability in Section 3. 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 details of how ECN is used with RTP over UDP are defined in Section 7. In Section 8 we describe how ECN is handled in RTP translators and mixers. Section 9 discusses some implementation considerations, Section 10 lists IANA considerations, and Section 11 discusses security considerations.
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].
Abbreviations and Definitions:
Note that 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.
ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960], and DCCP [RFC4340] transports. These are all unicast protocols which negotiate the use of ECN during the initial connection establishment handshake (supporting incremental deployment, and checking if ECN marked packets pass all middleboxes on the path). ECN-CE marks are immediately echoed back to the sender by the receiving end-point using an additional bit in feedback messages, and the sender then interprets the mark as equivalent to a packet loss for congestion control purposes.
If RTP is run over TCP, SCTP, or DCCP, it can use the native ECN support provided by those protocols. This memo does not concern itself further with these use cases. However, RTP is more commonly run over UDP. This combination does not currently support ECN, and we observe that it has significant differences from the other transport protocols for which ECN has been specified. These include:
These differences will significantly alter the shape of ECN support in RTP-over-UDP compared to ECN support in TCP, SCTP, and DCCP, but do not invalidate the need for ECN support.
ECN support is more important for RTP sessions than, for instance, is the case for TCP. This is because the impact of packet loss in real-time audio-visual media flows is highly visible to users. Effective ECN support for RTP flows running over UDP will allow real-time audio-visual applications to respond to the onset of congestion before routers are forced to drop packets, allowing those applications to control how they reduce their transmission rate, and hence media quality, rather than responding to, and trying to conceal the effects of unpredictable packet loss. Furthermore, widespread deployment for ECN and active queue management in routers, should it occur, can potentially reduce unnecessary queueing delays in routers, lowering the round-trip time and benefiting interactive applications of RTP, such as voice telephony.
Considering ECN, transport protocols supporting ECN, and RTP based applications one can create a set of requirements that must be satisfied to at least some degree if ECN is to used by RTP over UDP.
The following sections describes how these requirements can be met for RTP over UDP.
The use of ECN with RTP over UDP is dependent on negotiation of ECN capability between the sender and receiver(s), and validation of ECN support in all elements of the network path(s) traversed. RTP is used in a heterogeneous range of network environments and topologies, with various different signalling protocols. The mechanisms defined here make it possible to verify support for ECN in each of these environments, and irrespective of 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.
The use of ECN is further dependent on a capability of the RTP media flow to react to congestion signalled by ECN marked packets. Depending on the application, media codec, and network topology, this adaptation can occur in various forms and at various nodes. As an example, the sender can change the media encoding, or the receiver can change the subscription to a layered encoding, or either reaction can be accomplished by a transcoding middlebox. RFC 5117 identifies seven topologies in which RTP sessions may be configured, and which may affect the ability to use ECN:
It is recognised that ECN and RTCP processing in an RTP translator that modifies the media stream is non-trivial.
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 ensures that both senders and receivers will know about ECN-CE markings and any packet losses. Thus the actual decision point for the congestion control is not relevant. This is a great benefit as the rate of an RTP session can be varied in a number of ways, for example a unicast media sender might use TFRC [RFC5348] or some other algorithm, while a multicast session could use a sender based scheme adapting to the lowest common supported rate, or a receiver driven mechanism using layered coding to support more heterogeneous paths.
To ensure timely feedback of ECN-CE marked packets 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] does not allow any early or immediate transmission of RTCP feedback, and has a minimal RTCP interval whose default value (5 seconds) is many times the normal RTT between sender and receiver.
The interoperability requirements for this specification are that there is at least one common interoperability point for all implementations. Since initialization using RTP and RTCP (Section 7.2.1) is the one method that works in all cases, although is not optimal for all uses, it is selected as mandatory to implement this initialisation method. This method requires both the RTCP XR extension and the ECN feedback format, which require the RTP/AVPF profile to ensure timely feedback.
When one considers all the uses of ECN for RTP it is clear that there exist congestion control mechanisms that are receiver driven only [sec-congestion]. These congestion control mechanism do not require timely feedback of congestion events to the sender. If such a congestion control mechanism is combined with an initialization method that also doesn't require timely feedback using RTCP, like the leap of faith or the ICE based method then neither the ECN feedback format nor the RTP/AVPF profile would appear to be needed. However, fault detection can be greatly improved by using receiver side detection (Section 7.4.1) and early reporting of such cases using the ECN feedback mechanism.
For interoperability we mandate the implementation of the RTP/AVPF profile, with both RTCP extensions and the necessary signalling to support a common operations mode. This specification recommends the use of RTP/AVPF in all cases as negotiation of the common interoperability point requires RTP/AVPF, mixed negotiation of RTP/AVP and RTP/AVPF depending on other SDP attributes in the same media block is difficult, and the fact that fault detection can be improved when using RTP/AVPF.
The use of the ECN feedback format is also recommended, but cases exist where its use is not required due to no need for timely feedback. These will be explicitly noted using the term "no timely feedback required", and generally occur in combination with receiver driven congestion control, and with the leap-of-faith and ICE-based initialization methods. We also note that any receiver driven congestion control solution that still requires RTCP for signalling of any adaptation information to the sender will still require RTP/AVPF for timeliness.
The solution for using ECN with RTP over UDP/IP consists of four different pieces that together make the solution work:
Before an RTP session can be created, a signalling protocol is used to negotiate or at least configure session parameters (see Section 7.1). In some topologies the signalling protocol can also be used to discover the other participants. One of the parameters that must be agreed is the capability of a participant to support ECN. Note that all participants having the capability of supporting ECN does not necessarily imply that ECN is usable in an RTP session, since there may be middleboxes on the path between the participants which don't pass ECN-marked packets (for example, a firewall that blocks traffic with the ECN bits set). This document defines the information that needs to be negotiated, and provides a mapping to SDP for use in both declarative and offer/answer contexts.
When a sender joins a session for which all participants claim to support ECN, it must verify if that support is usable. There are three ways in which this verification can be done:
The first mechanism, using RTP with RTCP feedback, has the advantage of working for all RTP sessions, but the disadvantages of potential clipping if ECN marked RTP packets are discarded by middleboxes, and slow verification of ECN support. The STUN-based mechanism is faster to verify ECN support, but only works in those scenarios supported by end-to-end STUN, such as within an ICE exchange. The third one, leap-of-faith, has the advantage of avoiding additional tests or complexities and enabling ECN usage from the first media packet. The downside is that if the end-to-end path contains middleboxes that do not 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 requiring reaction, is the presence of a middlebox that re-marks ECT marked packets to non-ECT, possibly marking packets with an ECN-CE mark as non-ECT. This could result in increased levels of congestion due to non-responsiveness, and impact media quality as applications end up relying on packet loss as an indication of congestion.
Once ECN support has been verified (or assumed) to work for all receivers, a sender marks all its RTP packets as ECT packets, while 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 also counts the total number of ECN-CE marked packets as a cumulative sum. This is the mechanism to provide 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 has been reported. Section 7.3 describes the ongoing use of ECN within an RTP session.
This rapid feedback is not optimised for reliability, so another mechanism, RTCP XR ECN summary reports, is used to ensure more reliable, but less timely, reporting of the ECN information. The ECN summary report contains the same information as the ECN feedback format, only packed differently for better efficiency with reports for many sources. It is sent in a compound RTCP packet, along with regular RTCP reception reports. By using cumulative counters for observed ECN-CE, ECT, not-ECT, packet duplication, and packet loss the sender can determine what events have happened since the last report, independently of any RTCP packets having been lost.
RTCP reports MUST NOT be ECT marked, since ECT marked traffic may be dropped if the path is not ECN compliant. RTCP is used to provide feedback about what has been transmitted and what ECN markings that are received, so it is important that it is received in cases when ECT marked traffic is not getting through.
There are numerous reasons why the path the RTP packets take from the sender to the receiver may change, e.g., mobility, link failure followed by re-routing around it. Such an event may result in the packet being sent through a node that is ECN non-compliant, thus re-marking or dropping packets with ECT set. To prevent this from impacting the application for longer than necessary, the operation of ECN is constantly monitored by all senders (Section 7.4). Both the RTCP XR ECN summary reports and the ECN feedback packets allow the sender to compare the number of ECT(0), ECT(1), and non-ECT marked packets received with the number that were sent, while also reporting ECN-CE marked and lost packets. If these numbers do not agree, it can be inferred that the path does not reliably pass ECN-marked packets. A sender detecting a possible ECN non-compliance issue should then stop sending ECT marked packets to determine if that allows the packets to be correctly delivered. If the issues can be connected to ECN, then ECN usage is suspended.
This memo defines two new RTCP extensions: one RTP/AVPF [RFC4585] transport layer feedback format for urgent ECN information, and one RTCP XR [RFC3611] ECN summary report block type for regular reporting of the ECN marking information.
This RTP/AVPF transport layer feedback format is intended for use in RTP/AVPF early or immediate feedback modes when information needs to urgently reach the sender. Thus its main use is to report reception of an ECN-CE marked RTP packet so that the sender may perform congestion control, or to speed up the initiation procedures by rapidly reporting that the path can support ECN-marked traffic. The feedback format is also defined with reduced size RTCP [RFC5506] in mind, where RTCP feedback packets may be sent without accompanying Sender or Receiver Reports that would contain the Extended Highest Sequence number and the accumulated number of packet losses. Both are important for ECN to verify functionality and keep track of when CE marking does occur.
The RTP/AVPF transport layer feedback packet starts with the common header defined by the RTP/AVPF profile [RFC4585] which is reproduced in Figure 1. The FMT field takes the value [TBA1] to indicate that the Feedback Control Information (FCI) contains ECN Feedback report, as defined 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=TBA1| PT=RTPFB=205 | length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of packet sender | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSRC of media source | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : Feedback Control Information (FCI) : : :
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loss Packet Counter | Duplication Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ECN Feedback Report contains the following fields:
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). Multiple sources can be reported by including multiple ECN Feedback Reports packets in an compound RTCP packet.
The counters SHALL be initiated to 0 for each new SSRC received. This to enable detection of ECN-CE marks or Packet loss on the initial report from a specific participant.
The use of at least 32-bit counters allows even extremely high packet volume applications to not have wrapping of counters within any timescale close to the RTCP reporting intervals. However, 32-bits are not sufficiently large to disregard the fact that wrappings may happen during the life time of a long-lived RTP session. Thus handling of wrapping of these counters MUST be supported. It is recommended that implementations uses local representation of these counters that are longer than 32-bits to enable easy handling of wraps.
There is a difference in packet duplication reports between the packet loss counter that is defined in the Receiver Report Block [RFC3550] and that defined here. To avoid holding state for what RTP sequence numbers have been received, [RFC3550] specifies that one can count packet loss by counting the number of received packets and comparing it to the number of packets expected. As a result a packet duplication can hide a packet loss. However, when populating the ECN Feedback report, a receiver needs to track the sequence numbers actually received and count duplicates and packet loss separately to provide a more reliable indication. Reordering may however still result in that packet loss is reported in one report and then removed 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, in fact it is required to ensure complete tracking of the ECN state. If one of the clones was ECN-CE marked that is still an indication of congestion. Packet duplication has potential impact on the ECN verification and thus there is a need to count the duplicates.
This unilateral XR report block combined with RTCP SR or RR report blocks carries the same information as the ECN Feedback Report and is be based on the same underlying information. However, the ECN Feedback Report is intended to report on an ECN-CE mark as soon as possible, while this extended report is for the regular RTCP reporting and continuous verification of the ECN functionality end-to-end.
The ECN Summary report block consists 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=[TBA2] | Reserved | Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loss Packet Counter | Duplication Counter | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RTCP XR ECN Summary Report contains the following fields:
The Extended Highest Sequence number counter for each SSRC is not present in RTCP XR report, in contrast to the feedback version. The reason is that this summary report will rely on the information sent in the Sender Report (SR) or Receiver Report (RR) blocks part of the same RTCP compound packet. The Extended Highest Sequence number is available from the SR or RR.
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 are so large that the combination of SR/RR and the ECN summary for all the senders exceed the MTU, then only a subset of the senders SHOULD be included so that the reports for the subset fits within the MTU. The subsets SHOULD be selected round-robin across multiple intervals so that all sources are periodically reported. In case there are no SSRCs that currently are counted as senders in the session, the report block SHALL still be sent with no report block entry and a zero report block length to continuously indicate to the other participants the receiver capability to report ECN information.
This section defines a number of SDP signalling extensions used in the negotiation of the ECN for RTP support when using SDP. This includes one SDP attribute "ecn-capable-rtp" that negotiates the actual operation of ECN for RTP. Two SDP signalling parameters are defined to indicate the use of the RTCP XR ECN summary block and the RTP/AVPF feedback format for ECN. One ICE option SDP representation is also defined.
One new SDP attribute, "a=ecn-capable-rtp", is defined. This is a media level attribute, and MUST NOT be used at the session level. It is not subject to the character set chosen. The aim of this signalling is to indicate the capability of the sender and receivers to support ECN, and to negotiate the method of ECN initiation to be used in the session. The attribute takes a list of initiation methods, ordered in decreasing preference. The defined values for the initiation method are:
Further methods may be specified in the future, so unknown methods MUST be ignored upon reception.
In addition, a number of OPTIONAL parameters may be included in the "a=ecn-capable-rtp" attribute as follows:
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-7E / %x80-FF
; any 8-bit ASCII except <">
; external references:
; token: from RFC 4566
; SP and DQUOTE from RFC 5234
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 of each RTP session for which it wishes 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 following. The answering party compares the list of initiation methods in the offer with those it supports in order of preference. If there is a match, and if the receiver wishes to attempt to use ECN in the session, it includes an "a=ecn-capable-rtp" attribute containing its single preferred choice of initiation method, and any optional parameters, in the media sections of the answer. If there is no matching initiation method capability, or if the receiver does not wish to attempt to use 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 initialization 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, as expressed by the optional "mode=" parameter, determines whether ECN support can be negotiated for flows in one or both directions:
In an RTP session using multicast and ECN, participants that intend to send RTP packets SHOULD support setting ECT marks in RTP packets (i.e., should be "mode=setonly" or "mode=setread"). Participants receiving data need the capability to read ECN marks on incoming packets. It is important that receivers can read ECN marks (are "mode=readonly" or "mode=setread"), since otherwise no sender in the multicast session will be able to enable ECN. Accordingly, receivers that are "mode=setonly" SHOULD NOT join multicast RTP sessions that use ECN. If session participants that are not aware of the ECN for RTP signalling are invited to a multicast session, and simply 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 indicates a preference for the sending behaviour of the answering party, and its value in the answer indicates a sending preference for the behaviour of the offering party. It will be the senders choice to honour the receivers 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 new parameters may be introduced and verified to be supported by the other end-point by having them include it in any answer.
When SDP is used in a declarative manner, for example in a multicast session using the Session Announcement Protocol (SAP, [RFC2974]), negotiation of session description parameters is not possible. The "a=ecn-capable-rtp" attribute MAY be added to the session description to indicate that 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 have the capability to receive ECN-marked UDP packets, implement the method of initiation, and can generate RTCP ECN feedback. The mode parameter MAY also be included in declarative usage, to indicate the minimal capability is required by the consumer of the SDP. So for example in a SSM session the participants configured with a particular SDP will all be in a media receive only mode, thus mode=readonly will work as the capability of reporting on the ECN markings in the received is what is required. However, using "mode=readonly" also in ASM sessions is reasonable, unless all senders are required to attempt to use ECN for their outgoing RTP data traffic, in which case the mode needs to be set to "setread".
The "a=ecn-capable-rtp" attribute MAY be used with RTP media sessions using UDP/IP transport. It MUST NOT be used for RTP sessions using TCP, SCTP, or DCCP transport, or for non-RTP sessions.
As described in Section 7.3.3, RTP sessions using ECN require rapid RTCP ECN feedback, unless timely feedback is not required due to a receiver driven congestion control. To ensure that the sender can react to ECN-CE marked packets timely feedback is usually required. Thus, the use of the Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) [RFC4585] or other profile that inherits RTP/AVPF's signalling rules, MUST be signalled unless timely feedback is not required. If timely feedback is not required it is still RECOMMENDED to use RTP/AVPF. The signalling of an RTP/AVPF based profile is likely to be required even if the preferred method of initialization and the congestion control does not require timely feedback, as the common interoperable method is likely to be signalled or the improved fault reaction is desired.
A new "nack" feedback parameter "ecn" is defined to indicate the usage of the RTCP ECN feedback packet format [sec-rtcp-ecn-fb]. The ABNF [RFC5234] definition of the SDP parameter extension is:
rtcp-fb-nack-param = <See section 4.2 of RFC 4585> rtcp-fb-nack-param /= ecn-fb-par ecn-fb-par = SP "ecn"
The offer/answer rules for this SDP feedback parameters are specified in the RTP/AVPF profile [RFC4585].
A new unilateral RTCP XR block for ECN summary information is specified, thus the XR block SDP signalling also needs to be extended with a parameter. This is done in the same way as for the other XR blocks. The XR block SDP attribute as defined in Section 5.1 of the RTCP XR specification [RFC3611] is defined to be extensible. As no parameter values are needed for this ECN summary block, this parameter extension consists of a simple parameter name used to indicate 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, see the RTCP XR specification [RFC3611] and its description of how to handle unilateral parameters.
One new ICE [RFC5245] option, "rtp+ecn", is defined. This is used with the SDP session level "a=ice-options" attribute in an SDP offer to indicate that the initiator of the ICE exchange has the capability to support ECN for RTP-over-UDP flows (via "a=ice-options: rtp+ecn"). The answering party includes this same attribute at the session level in the SDP answer if it also has the capability, and removes the attribute if it does not wish to use ECN, or doesn't have the capability to use ECN. If the ICE initiation method (Section 7.2.2) is actually going to be used, it is also needs to be explicitly negotiated using the "a=ecn-capable-rtp" attribute. This ICE option SHALL be included when the ICE initiation method is offered or declared in the SDP.
In the detailed specification of the behaviour below, the different functions in the general case will first be discussed. In case special considerations are needed for middleboxes, multicast usage etc, those will be specially discussed in related subsections.
The first stage of ECN negotiation for RTP-over-UDP is to signal the capability to use ECN. An RTP system that supports ECN and uses SDP for its signalling MUST implement the SDP extension to signal ECN capability as 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 described in Section 6.4. Other signalling systems will need to define signalling parameters corresponding to those defined for SDP.
The "ecn-capable-rtp" SDP attribute MUST be used when employing ECN for RTP according to this specification in systems using SDP. As the RTCP XR ECN summary report is required independently of the initialization method or congestion control scheme, 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 initialization method or a congestion control algorithm requires timely sender side knowledge of received CE markings. If the congestion control scheme requires additional signalling, this should be indicated as appropriate.
Once the sender and the receiver(s) have agreed that they have the capability to use ECN within a session, they may attempt to initiate ECN use. All session participants connected over the same transport MUST use the same initiation method. RTP mixers or translators can use different initiation methods to different participants that are connected over different underlying transports. The mixer or translator will need to do individual signalling with each participant to ensure it is consistent with the ECN support in those cases where it does not function as one end-point for the ECN control loop.
At the start of the RTP session, when the first packets with ECT are sent, it is important to verify that IP packets with ECN field values of ECT or ECN-CE will reach their destination(s). There is some risk that the use of ECN will result in either reset of the ECN field, or loss of all packets with ECT or ECN-CE markings. If the path between the sender and the receivers exhibits either of these behaviours one 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 is to ensure that packet loss due to ECN marking will not effect the RTCP traffic and the necessary feedback information it carries.
An RTP system that supports ECN MUST implement the initiation of ECN using in-band RTP and RTCP described in Section 7.2.1. It MAY also implement other mechanisms to initiate ECN support, for example the STUN-based mechanism described in Section 7.2.2, or use the leap of faith option if the session supports the limitations provided in Section 7.2.3. If support for both in-band and out-of-band mechanisms are signalled, the sender when negotiating SHOULD offer detection of ECT using STUN with ICE with higher priority than detection of ECT using RTP and RTCP.
No matter how ECN usage is initiated, the sender MUST continually monitor the ability of the network, and all its receivers, to support ECN, following the mechanisms described in Section 7.4. This is necessary because path changes or changes in the receiver population may invalidate the ability of the system to use ECN.
The ECN initiation phase using RTP and RTCP to detect if the network path supports ECN comprises three stages. Firstly, the RTP sender generates some small fraction of its traffic with ECT marks to act as probe for ECN support. Then, on receipt of these ECT-marked packets, the receivers send RTCP ECN feedback packets and RTCP ECN summary reports to inform the sender that their path supports ECN. Finally, the RTP sender makes the decision to use ECN or not, based on whether the paths to all RTP receivers have been verified to support ECN.
If the ECN negotiation succeeds, this indicates that the path can pass some ECN-marked traffic, and that the receivers support ECN feedback. This does not necessarily imply that the path can robustly convey ECN feedback; Section 7.3 describes the ongoing monitoring that must be performed to ensure the path continues to robustly support ECN.
When a sender or receiver detects ECN failures on paths they should log these to enable follow up and statistics gathering regarding broken paths. The logging mechanism used is implementation dependent.
This section describes an OPTIONAL method that can be used to avoid media impact and also ensure an ECN capable path prior to media transmission. This method is considered in the context where the session participants are using ICE [RFC5245] to find working connectivity. We need to use ICE rather than STUN only, as the verification needs to happen from the media sender to the address and port on which the receiver is listening.
Note that this method is only applicable to sessions when the remote destinations are unicast addresses. In addition, transport translators that do not terminate the ECN control loop and may distribute received packets to more than one other receiver must either disallow this method (and use the RTP/RTCP method instead), or implement additional handling as discussed below. This is because the ICE initialization method verifies the underlying transport to one particular address and port. If the receiver at that address and port intends to use the received packets in a multi-point session then the tested capabilities and the actual session behavior are not matched.
To minimise the impact of set-up delay, and to prioritise the fact that one has a working connectivity rather than necessarily finding the best ECN capable network path, this procedure is applied after having performed a successful connectivity check for a candidate, which is nominated for usage. At that point an additional connectivity check is performed, sending the "ECN Check" attribute in a STUN packet that is ECT marked. On reception of the packet, a STUN server supporting this extension will note the received ECN field value, and send a STUN/UDP/IP packet in reply with the ECN field set to not-ECT and including an ECN check attribute. A STUN server that doesn't understand the extension, or is incapable of reading the ECN values on incoming STUN packets, should follow the rule in the STUN specification for unknown comprehension-optional attributes, and ignore the attribute, resulting in the sender receiving a STUN response without the ECN Check STUN attribute.
The ECN STUN checks can be lost on the path, for example due to the ECT marking, but also various other non ECN related reasons causing packet loss. The goal is to detect when the ECT markings are rewritten or if it is the ECT marking that causes packet loss so that the path can be determined as not ECT. Other reasons for packet loss should not result in a failure to verify the path as ECT. Therefore a number of retransmissions should be attempted. But, the sender of ECN STUN checks will also have to set a criteria for when it gives up testing for ECN capability on the path. As the ICE agent have successfully verified the path a RTT measurement for this path can be performed. To have high probability of succesfully verifying the path it is RECOMMENDED that the client retransmitt the ECN STUN check 4 times. The interval between the retransmissions will be based on the Ta timer as defined in Section 16.1 for RTP Media Streams in ICE [RFC5245]. The number of ECN STUN checks needing to be sent will depend on the number of ECN capable flows (N) that is to be established. The interval between each transmission of an ECN check packet MUST be Ta. In other words for a given flow being verified for ECT the RTO is set to Ta*N. The transmission for that flow is stopped when an ECN Check STUN response has been received, which don't indicate to retransmit the request due to temporary error, 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 STUN ECN check attribute contains one field and a flag, as shown in Figure 8. The flag indicates whether the echo field contains a valid value or not. The field is the ECN echo field, and when valid contains 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| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This attribute MAY be included in any STUN request to request the ECN field to be echoed back. In STUN requests the V bit SHALL be set to 0. A compliant STUN server receiving a request with the ECN Check attribute SHALL read the ECN field value of the IP/UDP packet the request was received in. Upon forming the response the server SHALL include the ECN Check attribute setting the V bit to valid and include the read value of the ECN field into the ECF field. If the STUN responder was unable to ascertain, due to temporary errors, the ECN value of the STUN request, it SHALL set the V bit in the response to 0. The STUN client may retry immediately.
The ICE based initialization method does require some special consideration when used by a translator. This is especially for transport translators and translators that fragment or reassemble packets, since they do not separate the ECN control loops between the end-points and the translator. When using ICE-based initiation, such a translator must ensure that any participants joining an RTP session for which 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 session, the translator will perform a check towards the new participant. If that is successfully completed the ECT properties of the session are maintained for the other senders in the session. If the check fails then the existing senders will now see a participant that fails to receive ECT. Thus the failure detection in those senders will eventually detect this. However 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 non-ECT. Any packet intended to be forward that are ECN-CE marked SHALL be discard and not sent. In cases where the path from a new participant to the translator fails the ECT check then only that sender will not contribute any ECT marked traffic towards the translator.
This method for initiating ECN usage is a leap of faith that assumes that ECN will work on the used path(s). The method is to go directly to "ongoing use of ECN" as defined in Section 7.3. Thus all RTP packets MAY be marked as ECT and the failure detection MUST be used to detect any case when the assumption that the path was 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 to be ECT.
If the sender marks all packets as ECT while transmitting on a path that contains an ECN-blocking middlebox, then receivers downstream of that middlebox will not receive any RTP data packets from the sender, and hence will not consider it to be an active RTP SSRC. The sender can detect this and revert to sending packets without ECT marks, since RTCP SR/RR packets from such receivers will either not include a report for sender's SSRC, or will report that no packets have been received, but this takes at least one RTCP reporting interval. It should be noted that a receiver might generate its first RTCP packet immediately on joining a unicast session, or very shortly after joining a RTP/AVPF session, before it has had chance to receive any data packets. A sender that receives RTCP SR/RR packet indicating lack of reception by a receiver SHOULD therefore wait for a second RTCP report from that receiver to be sure that the lack of reception is due to ECT-marking. Since this recovery process can take several tens of seconds, during which time the RTP session is unusable for media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation method be used in environments where ECN-blocking middleboxes are likely to be present.
Once ECN has been successfully initiated for an RTP sender, that sender begins sending all RTP data packets as ECT-marked, and its receivers send ECN feedback information via RTCP packets. This section describes procedures for sending ECT-marked data, providing ECN feedback information via RTCP, and responding to ECN feedback information.
After a sender has successfully initiated ECN use, it SHOULD mark all the RTP data packets it sends as ECT. The sender SHOULD mark packets as ECT(0) unless the receiver expresses a preference for ECT(1) or random using the "ect" parameter in the "a=ecn-capable-rtp" attribute.
The sender SHALL NOT include ECT marks on outgoing RTCP packets, and SHOULD NOT include ECT marks on any other outgoing control messages (e.g., STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or ZRTP [RFC6189] control packets) that are multiplexed on the same UDP port. For control packets there might be exceptions, like the STUN based ECN check defined in Section 7.2.2.
An RTP receiver that receives 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 report this back to the sender 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 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 reduce the size of the feedback message, reduced size RTCP [RFC5506] MAY be used if supported by the end-points. Both RTP/AVPF and reduced size RTCP MUST be negotiated in the session set-up signalling before they can be used.
Every time a regular compound RTCP packet is to be transmitted, 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, that occurs when many receivers simultaneously send feedback to a single sender, must be considered. The RTP/AVPF transmission rules will limit the amount of feedback that can be sent, avoiding the implosion problem but also delaying feedback by varying degrees from nothing up to a full RTCP reporting interval. As a result, 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, allowing the sender to react on a single or a few reports.
The reception of RTP packets with ECN-CE marks in the IP header is a notification that congestion is being experienced. The default reaction on the reception of these ECN-CE marked packets MUST be to provide the congestion control algorithm with a congestion notification that triggers the algorithm 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.
We note that there MAY be other reactions to ECN-CE specified in the future. Such an alternative reaction MUST be specified and considered to be safe for deployment under any restrictions specified. A potential example for an alternative reaction could be emergency communications (such as that generated by first responders, as opposed to the general public) in networks where the user has been authorized. A more detailed description of these other reactions, as well as the types of congestion control algorithms used by end-nodes, is outside of 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:
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 which ignores ECN Congestion Experienced feedback is not immune to congestion: the network will eventually begin to discard packets if traffic doesn't respond. It is in the best interest of an application to respond to ECN congestion feedback promptly, to avoid packet loss.
Senders and receivers can deliberately ignore ECN-CE and thus get a benefit over behaving flows (cheating). Th 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 about the senders acting on the behalf of the network may be reduced 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 nonce can be applicable also for RTP, it is not included in this specification. This as a receiver interested in cheating would simple claim to not support 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 both the media sender and receivers interest 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 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 doesn't agree there are two likely reasons, a translator changing the stream or not carrying the ECN markings forward, or that some node re-marks 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 behavior is happening on the path.
Thus packet losses and non-matching ECN field value statistics are possible indication of issues with using ECN over the path. The next section defines both sender and receiver reactions to these cases.
Upon the detection of a potential failure, both the sender and the receiver can react to mitigate the situation.
A receiver that detects a packet loss burst MAY schedule an early feedback packet that includes at least the RTCP RR and the ECN feedback message to report this to the sender. This will speed up the detection of the loss at the sender, thus triggering sender side mitigation.
A sender that detects high packet loss rates for ECT-marked packets SHOULD immediately switch to sending packets as not-ECT to determine if the losses are potentially due to the ECT markings. If the losses disappear when the ECT-marking is discontinued, the RTP sender should go back to initiation procedures to attempt to verify the apparent loss of ECN capability of the used path. If a re-initiation fails then the two possible actions exist:
We foresee the possibility of flapping ECN capability due to several reasons: video switching MCU or similar middleboxes that selects to deliver media from the sender only intermittently; load balancing devices may in worst case result in that some packets take a different network path than the others; mobility solutions that switch underlying network path in a transparent way for the sender or receiver; and membership changes in a multicast group. It is however appropriate to mention that there are also issues such as re-routing of traffic due to a flappy route table or excessive reordering and other issues that are not directly ECN related but nevertheless may cause problems for ECN.
This section contains discussion on how the ECN summary report information can be used to detect various types of ECN path issues. We first review the information the RTCP reports provide on a per source (SSRC) basis:
The counters will be initialised to zero to provide value for the RTP stream sender from the first report. After the first report, the changes between the last received report and the previous report are determined by simply taking the values of the latest minus the previous, taking wrapping into account. This definition is also robust to packet losses, since if one report is missing, the reporting interval becomes longer, but is otherwise equally valid.
In a perfect world, the number of not-ECT packets received should be equal to the number sent minus the lost packets counter, and the sum of the ECT(0), ECT(1), and ECN-CE counters should be equal to the number of ECT marked packet sent. Two issues may cause a mismatch in these statistics: severe network congestion or unresponsive congestion control might cause some ECT-marked packets to be lost, and packet duplication might result in some packets being received, and counted in the statistics, multiple times (potentially with a different ECN-mark on each copy of the duplicate).
The rate of packet duplication is tracked, allowing one to take the duplication into account. The value of the ECN field for duplicates will also be counted and when comparing the figures one needs to take some fraction of packet duplicates that are non-ECT and some fraction of packet duplicates being ECT into account into the calculation. Thus when only sending non-ECT then the number of sent packets plus reported duplicates equals the number of received non-ECT. When sending only ECT then number of sent ECT packets plus duplicates will equal ECT(0), ECT(1), ECN-CE and packet loss. When sending a mix of non-ECT and ECT then there is an uncertainty if any duplicate or packet loss was an non-ECT or ECT. If the packet duplication is completely independent of the usage of ECN, then the fraction of packet duplicates should be in relation to the number of non-ECT vs ECT packet sent during the period of comparison. This relation does not hold for packet loss, where higher rates of packet loss for non-ECT is expected 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 changed towards not-ECT, then this is clearly an indication that the path results in clearing of the ECT field.
Dropping of ECT packets: To determine if the packet drop ratio is different between not-ECT and ECT marked transmission requires a mix of transmitted traffic. The sender should compare if the delivery percentage (delivered / transmitted) between ECT and not-ECT is significantly different. Care must be taken if the number of packets are low in either of the categories. One must also take into account the level of CE marking. A CE marked packet would have been dropped unless it was ECT marked. Thus, the packet loss level for not-ECT should be approximately equal to the loss rate for ECT when counting the CE marked packets as lost ones. A sender performing this calculation needs to ensure that the difference is statistically significant.
If erroneous behavior is detected, it should be logged to enable follow up and statistics gathering.
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. This includes both downstream RTCP reports generated by the media sender, and also reports generated by the receivers, flowing upstream back towards the sender.
Some translators only perform transport level translations, like copying packets from one address domain, like unicast to multicast. It may also perform relaying like copying an incoming packet to a number of unicast receivers. This section details the ECN related actions for RTP and RTCP.
For the 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, unless the translator itself is overloaded and experiencing congestion, in which case it may mark the outgoing datagrams with an ECN-CE mark.
A Transport translator does not modify RTCP packets. It however MUST perform the corresponding transport translation of the RTCP packets as it does with RTP packets being sent from the same source/end-point.
An RTP translator may fragment or reassemble RTP data packets without changing the media encoding, and without reference to the congestion state of the networks it bridges. An example of this might be to combine packets of a voice-over-IP stream coded with one 20ms frame per RTP packet into new RTP packets with two 20ms frames per packet, thereby reducing the header overheads and so stream bandwidth, at the expense of an increase in latency. If multiple data packets are re-encoded into one, or vice versa, the RTP translator MUST assign new sequence numbers to the outgoing packets. Losses in the incoming RTP packet stream may also induce corresponding gaps in the outgoing RTP sequence numbers. An RTP translator MUST rewrite RTCP packets to make the corresponding changes to their sequence numbers, and to reflect the impact of the fragmentation or reassembly. This section describes how that rewriting is to be done for RTCP ECN feedback packets. Section 7.2 of [RFC3550] describes general procedures for other RTCP packet types.
The processing of arriving RTP packets for this case is as follows. If an ECN marked packet is split into two, then both the outgoing packets MUST be ECN marked identically to the original; if several ECN marked packets are combined into one, the outgoing packet MUST be either ECN-CE marked or dropped if any of the incoming packets are ECN-CE marked. If the outgoing combined packet is not ECN-CE marked, then it MUST be ECT marked if any of the incoming packets were ECT marked.
RTCP ECN feedback packets (Section 5.1) contain seven fields that are rewritten in an RTP translator that fragments or reassembles packets: the extended highest sequence number, the duplication counter, the lost packets counter, the ECN-CE counter, and not-ECT counter, the ECT(0) counter, and the ECT(1) counter. The RTCP XR report block for ECN summary information (Section 5.2) includes all of these fields except the extended highest sequence number which is present in the report block in an SR or RR packet. The procedures for rewriting these fields are the same for both RTCP ECN feedback packet and the RTCP XR ECN summary packet.
When receiving an RTCP ECN feedback packet for the translated stream, an RTP translator first determines the range of packets to which the report corresponds. The extended highest sequence number in the RTCP ECN feedback packet (or in the RTCP SR/RR packet contained within the compound packet, in the case of RTCP XR ECN summary reports) specifies the end sequence number of the range. For the first RTCP ECN feedback packet received, the initial extended sequence number of the range may be determined 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 subsequent RTCP ECN feedback packets, the starting sequence number may be determined as being one after the extended highest sequence number of the previous RTCP ECN feedback packet received from the same SSRC. These values are in the sequence number space of the translated packets.
Based on its knowledge of the translation process, the translator determines the sequence number range for the corresponding original, pre-translation, packets. The extended highest sequence number in the RTCP ECN feedback packet is rewritten to match the final sequence number in the pre-translation sequence number range.
The translator then determines 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) such that R = numTrans / numOrig. The counter values in the RTCP ECN feedback report are then scaled by dividing each of them by R. For example, if the translation process combines two RTP packets into one, then numOrig will be twice numTrans, giving R=0.5, and the counters in the translated RTCP ECN feedback packet will be twice those in the original.
The ratio, R, may have a value that leads to non-integer multiples of the counters when translating the RTCP packet. For example, a VoIP translator that combines two adjacent RTP packets into one if they contain active speech data, but passes comfort noise packets unchanged, would have an R values of between 0.5 and 1.0 depending on the amount of active speech. Since the counter values in the translated RTCP report are integer values, rounding will be necessary in this case.
When rounding counter values in the translated RTCP packet, the translator should try to ensure that they sum to the number of RTP packets in the pre-translation sequence number space (numOrig). The translator should also try to ensure that no non-zero counter is rounded to a zero value, unless the pre-translated values are zero, since that will lose information that a particular type of event has occurred. It is recognised that it may be impossible to satisfy both of these constraints; in such cases, it is better to ensure that no non-zero counter is mapped to a zero value, since this preserves congestion adaptation and helps the RTCP-based ECN initiation process.
One should be aware of the impact this type of translators have on the measurement of packet duplication. A translator performing aggregation and most likely also an fragmenting translator will suppress any duplication happening prior to itself. Thus the reports and what is being scaled will only represent packet duplication happening from the translator to the receiver reporting on the flow.
It should be noted that scaling the RTCP counter values in this way is meaningful only on the assumption that the level of congestion in the network is related to the number of packets being sent. This is likely to be a reasonable assumption in the type of environment where RTP translators that fragment or reassemble packets are deployed, as their entire purpose is to change the number of packets being sent to adapt to known limitations of the network, but is not necessarily valid in general.
The rewritten RTCP ECN feedback report is sent from the other side of the translator to that which it arrived (as part of a compound RTCP packet containing other translated RTCP packets, where appropriate).
An RTP translator that acts as a media transcoder cannot directly forward RTCP packets corresponding to the transcoded stream, since those packets will relate to the non-transcoded stream, and will not be useful in relation to the transcoded RTP flow. Such a transcoder will need to interpose itself into the RTCP flow, acting as a proxy for the receiver to generate RTCP feedback in the direction of the sender relating to the pre-transcoded stream, and acting in place of the sender to generate RTCP relating to the transcoded stream, to be sent towards the receiver. This section describes how this proxying is to be done for RTCP ECN feedback packets. Section 7.2 of [RFC3550] describes general procedures for other RTCP packet types.
An RTP translator acting as a media transcoder in this manner does not have its own SSRC, and hence is not visible to other entities at the RTP layer. RTCP ECN feedback packets and RTCP XR report blocks for ECN summary information that are received from downstream relate to the translated stream, and so must be processed by the translator as if it were the original media source. These reports drive the congestion control loop and 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 receiver, and must process RTCP ECN feedback and summary reports independently to the other transcoder instances. An RTP translator acting as a media transcoder in this manner MUST NOT forward RTCP ECN feedback packets or RTCP XR ECN summary reports from downstream receivers in the upstream direction.
An RTP translator acting as a media transcoder will generate RTCP reports upstream towards the original media sender, based on the reception quality of the original media stream at the translator. The translator will run a separate congestion control loop and media adaptation between itself and the media sender for each of its downstream receivers, and must generate RTCP ECN feedback packets and RTCP XR ECN summary reports for that congestion control loop using the SSRC of that downstream receiver.
An RTP mixer terminates one-or-more RTP flows, combines them into a single outgoing media stream, and transmits that new stream as a separate RTP flow. A mixer has its own SSRC, and is 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 relating to the RTP flows it terminates, in exactly the same way it would if it were an RTP receiver. These reports form part of the congestion control loop between the mixer and the media senders generating the streams it is mixing. A separate control loop runs between each sender and the mixer.
An ECN-aware RTP mixer will negotiate and initiate the use of ECN on the mixed RTP flows it generates, and will accept and process RTCP ECN feedback reports and RTCP XR report blocks for ECN relating to those mixed flows as if it were a standard media sender. A congestion control loop runs between the mixer and its receivers, driven in part by the ECN reports received.
An RTP mixer MUST NOT forward RTCP ECN feedback packets or RTCP XR ECN summary reports from downstream receivers in the upstream direction.
To allow the use of ECN with RTP over UDP, an RTP implementation desiring to support receiving ECN controlled media streams must support reading the value of the ECT bits on received UDP datagrams, and an RTP implementation desiring to support sending ECN controlled media streams must support setting the ECT bits in outgoing UDP datagrams. The standard Berkeley sockets API pre-dates the specification of ECN, and does not provide the functionality which is required for this mechanism to be used with UDP flows, making this specification difficult to implement portably.
Note to RFC Editor: please replace "RFC XXXX" below with the RFC number of this memo, and remove this note.
Following the guidelines in [RFC4566], the IANA is requested to register one new SDP attribute:
This attribute defines the ability to negotiate the use of ECT (ECN capable transport) for RTP flows running over UDP/IP. This attribute should be put in the SDP offer if the offering party wishes to receive an ECT flow. The answering party should include the attribute in the answer if it wish to receive an ECT flow. If the answerer does not include the attribute then ECT MUST be disabled in both directions.
The IANA is requested to register one new RTP/AVPF Transport Layer Feedback Message in the table of FMT values for RTPFB Payload Types [RFC4585] as defined in Section 5.1:
Name: RTCP-ECN-FB Long name: RTCP ECN Feedback Value: TBA1 Reference: RFC XXXX
The IANA is requested to register one new SDP "rtcp-fb" attribute "nack" parameter "ecn" in the SDP ("ack" and "nack" Attribute Values) registry.
Value name: ecn Long name: Explicit Congestion Notification Usable with: nack Reference: RFC XXXX
The IANA is requested to register one new RTCP XR Block Type as defined in Section 5.2:
Block Type: TBA2 Name: ECN Summary Report Reference: RFC XXXX
The IANA is requested to register one new RTCP XR SDP Parameter "ecn-sum" in the "RTCP XR SDP Parameters" registry.
Parameter name XR block (block type and name) -------------- ------------------------------------ ecn-sum TBA2 ECN Summary Report Block
A new STUN [RFC5389] attribute in the Comprehension-optional range under IETF Review (0x8000-0xFFFF) is request to be assigned to the STUN attribute defined in Section 7.2.2. The STUN attribute registry can currently be found at: http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml.
A new ICE option "rtp+ecn" is registered in the registry that "IANA Registry for Interactive Connectivity Establishment (ICE) Options" [RFC6336] creates.
The use of ECN with RTP over UDP as specified in this document has the following known security issues that need to be considered.
External threats to the RTP and RTCP traffic:
The following are threats that exist from misbehaving senders or receivers:
We note that the end-point security functions needed to prevent an external attacker from inferring 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 there exist multiple solutions possible depending on the application context. Secure RTP (SRTP) [RFC3711] does satisfy the requirement to protect this mechanism despite only providing authentication if a entity is within the security context or not. IPsec [RFC4301] and DTLS [RFC4347] 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. Here an appropriate mechanism to protect the used signalling needs to be used. For SIP/SDP ideally 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.
This section contain 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.
This example is a basic offer/answer SDP exchange, assumed done by SIP (not shown). The intention is to establish 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 8998
This SDP offer offers a single media stream with 3 media payload types. It proposes to use ECN with RTP, with the ICE based initialization as being preferred over the RTP/RTCP one. Leap of faith is not suggested to be used. The offerer is capable of both setting and reading the ECN bits. In addition the use of 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 to 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 host
The answer confirms that only one media stream will be used. One RTP Payload type was removed. ECN capability was confirmed, and the initialization method will be ICE. However, the answerer is only capable of reading the ECN bits, which means that 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 as the answerer has not indicated support for it in the answer.
The below session describes an any source multicast using session with a single media stream.
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-sum
In the above example, as this is declarative we need to require certain functionality. As it is ASM the initialization method that can work here is the RTP/RTCP based one. So that is indicated. The ECN setting and reading capability to take part of this session is at least read. If one is capable of setting that is good, but not required as one can skip using ECN for anything one sends oneself. The ECT value is recommended to be set to 0 always. The ECN usage in this session requires both ECN feedback and the XR ECN summary report, so their use is also indicated.
The authors wish to thank the following persons for their reviews and comments: Thomas Belling, Bob Briscoe, Roni Even, Kevin P. Flemming, Thomas Frankkila, Christian Groves, Christer Holmgren, Cullen Jennings Tom Van Caenegem, Simo Veikkolainen, Bill Ver Steeg, Dan Wing, Qin Wu, and Lei Zhu.