draft-ietf-avtcore-ecn-for-rtp-01.txt   draft-ietf-avtcore-ecn-for-rtp-02.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft I. Johansson Internet-Draft I. Johansson
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: September 15, 2011 C. Perkins Expires: December 2, 2011 C. Perkins
University of Glasgow University of Glasgow
P. O'Hanlon P. O'Hanlon
UCL UCL
K. Carlberg K. Carlberg
G11 G11
March 14, 2011 May 31, 2011
Explicit Congestion Notification (ECN) for RTP over UDP Explicit Congestion Notification (ECN) for RTP over UDP
draft-ietf-avtcore-ecn-for-rtp-01 draft-ietf-avtcore-ecn-for-rtp-02
Abstract Abstract
This document specifies how explicit congestion notification (ECN) This memo specifies how Explicit Congestion Notification (ECN) can be
can be used with Real-time Transport Protocol (RTP) over UDP flows used with Real-time Transport Protocol (RTP) running over UDP, using
that use RTP Control Protocol (RTCP) as feedback mechanism. It RTP Control Protocol (RTCP) as a feedback mechanism. It defines a
defines one RTP Control Protocol Extended Reports (RTCP XR) extension new RTCP Extended Report (XR) block for periodic ECN feedback, a new
for ECN summary, a RTCP transport feedback format for timely RTCP transport feedback message for timely reporting of congestion
reporting of congestion events, and an Session Traversal Utilities events, and a Session Traversal Utilities for NAT (STUN) extension
for NAT (STUN) extension used in the optional initilization method used in the optional initilization method using Interactive
using Interactive Connectivity Establishment (ICE). Signalling and Connectivity Establishment (ICE). Signalling and procedures for
procedures for negotiation of capabilities and initilization methods negotiation of capabilities and initilization methods are also
are also defined. defined.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 15, 2011. This Internet-Draft will expire on December 2, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 10 skipping to change at page 3, line 10
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 5 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 5
3. Discussion, Requirements, and Design Rationale . . . . . . . . 6 3. Discussion, Requirements, and Design Rationale . . . . . . . . 6
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Interoperability . . . . . . . . . . . . . . . . . . . . . 12 3.3. Interoperability . . . . . . . . . . . . . . . . . . . . . 11
4. Overview of Use of ECN with RTP/UDP/IP . . . . . . . . . . . . 12 4. Overview of Use of ECN with RTP/UDP/IP . . . . . . . . . . . . 12
5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 15 5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 15
5.1. RTP/AVPF Transport Layer ECN Feedback packet . . . . . . . 16 5.1. RTP/AVPF Transport Layer ECN Feedback packet . . . . . . . 15
5.2. RTCP XR Report block for ECN summary information . . . . . 19 5.2. RTCP XR Report block for ECN summary information . . . . . 18
6. SDP Signalling Extensions for ECN . . . . . . . . . . . . . . 20 6. SDP Signalling Extensions for ECN . . . . . . . . . . . . . . 20
6.1. Signalling ECN Capability using SDP . . . . . . . . . . . 20 6.1. Signalling ECN Capability using SDP . . . . . . . . . . . 20
6.2. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 24 6.2. RTCP ECN Feedback SDP Parameter . . . . . . . . . . . . . 25
6.3. XR Block SDP Parameter . . . . . . . . . . . . . . . . . . 25 6.3. XR Block ECN SDP Parameter . . . . . . . . . . . . . . . . 25
6.4. ICE Parameter to Signal ECN Capability . . . . . . . . . . 25 6.4. ICE Parameter to Signal ECN Capability . . . . . . . . . . 25
7. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 25 7. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 26
7.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 26 7.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 26
7.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 26 7.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 26
7.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 32 7.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 33
7.4. Detecting Failures . . . . . . . . . . . . . . . . . . . . 35 7.4. Detecting Failures . . . . . . . . . . . . . . . . . . . . 36
8. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 38 8. Processing ECN in RTP Translators and Mixers . . . . . . . . . 39
8.1. Fragmentation and Reassembly in Translators . . . . . . . 38 8.1. Transport Translators . . . . . . . . . . . . . . . . . . 40
8.2. Generating RTCP ECN Feedback in Media Transcoders . . . . 40 8.2. Fragmentation and Reassembly in Translators . . . . . . . 40
8.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 41 8.3. Generating RTCP ECN Feedback in Media Transcoders . . . . 42
9. Implementation considerations . . . . . . . . . . . . . . . . 42 8.4. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 43
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 9. Implementation considerations . . . . . . . . . . . . . . . . 44
10.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 42 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
10.2. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 42 10.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 44
10.3. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 43 10.2. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 44
10.4. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 43 10.3. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 45
10.5. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 43 10.4. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 45
10.6. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 43 10.5. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 45
10.7. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 43 10.6. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 45
11. Security Considerations . . . . . . . . . . . . . . . . . . . 43 10.7. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 45
12. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 46 11. Security Considerations . . . . . . . . . . . . . . . . . . . 46
12.1. Basic SDP Offer/Answer . . . . . . . . . . . . . . . . . . 46 12. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 48
12.2. Declarative Multicast SDP . . . . . . . . . . . . . . . . 48 12.1. Basic SDP Offer/Answer . . . . . . . . . . . . . . . . . . 48
13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 49 12.2. Declarative Multicast SDP . . . . . . . . . . . . . . . . 50
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 51
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52
15.1. Normative References . . . . . . . . . . . . . . . . . . . 50 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
15.2. Informative References . . . . . . . . . . . . . . . . . . 51 15.1. Normative References . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 15.2. Informative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
This document outlines how Explicit Congestion Notification (ECN) This memo outlines how Explicit Congestion Notification (ECN)
[RFC3168] can be used for Real-time Transport Protocol (RTP) [RFC3168] can be used for Real-time Transport Protocol (RTP)
[RFC3550] flows running over UDP/IP which use RTP Control Protocol [RFC3550] flows running over UDP/IP which use RTP Control Protocol
(RTCP) as a feedback mechanism. The solution consists of feedback of (RTCP) as a feedback mechanism. The solution consists of feedback of
ECN congestion experienced markings to the sender using RTCP, ECN congestion experienced markings to the sender using RTCP,
verification of ECN functionality end-to-end, and how to initiate ECN verification of ECN functionality end-to-end, and procedures for how
usage. The initiation process will have some dependencies on the to initiate ECN usage. The initiation process will have some
signalling mechanism used to establish the RTP session, a dependencies on the signalling mechanism used to establish the RTP
specification for signalling mechanisms using Session Description session, a specification for signalling mechanisms using Session
Protocol (SDP) [RFC4566] is included. Description Protocol (SDP) [RFC4566] is included.
ECN is getting attention as a method to minimise the impact of ECN is getting attention as a method to minimise the impact of
congestion on real-time multimedia traffic. When ECN is used, the congestion on real-time multimedia traffic. The use of ECN provides
network can signal to applications that congestion is occurring, a way for the network to send a congestion control signal to a media
whether that congestion is due to queuing at a congested link, transport without having to impair the media. Unlike packet loss,
limited resources and coverage on a radio link, or other reasons. ECN signals unambiguously indicate congestion to the transport as
ECN provides a way for networks to send congestion control signals to
a media transport without having to impair the media. Unlike losses,
the signals unambiguously indicate congestion to the transport as
quickly as feedback delays allow, and without confusing congestion quickly as feedback delays allow, and without confusing congestion
with losses that might have occurred for other reasons such as with losses that might have occurred for other reasons such as
transmission errors, packet-size errors, routing errors, badly transmission errors, packet-size errors, routing errors, badly
implemented middleboxes, policy violations and so forth. implemented middleboxes, policy violations and so forth.
The introduction of ECN into the Internet requires changes to both The introduction of ECN into the Internet requires changes to both
the network and transport layers. At the network layer, IP the network and transport layers. At the network layer, IP
forwarding has to be updated to allow routers to mark packets, rather forwarding has to be updated to allow routers to mark packets, rather
than discarding them in times of congestion [RFC3168]. In addition, than discarding them in times of congestion [RFC3168]. In addition,
transport protocols have to be modified to inform the sender that ECN transport protocols have to be modified to inform the sender that ECN
marked packets are being received, so it can respond to the marked packets are being received, so it can respond to the
congestion. TCP [RFC3168], SCTP [RFC4960] and DCCP [RFC4340] have congestion. The Transmission Control Protocol (TCP) [RFC3168],
been updated to support ECN, but to date there is no specification Stream Control Transmission Protocol (SCTP) [RFC4960] and Datagram
how UDP-based transports, such as RTP [RFC3550], can use ECN. This Congestion Control Protocl (DCCP) [RFC4340] have been updated to
is due to the lack of feedback mechanisms directly in UDP. Instead support ECN, but to date there is no specification how UDP-based
the signaling control protocol on top of UDP needs to provide that transports, such as RTP [RFC3550], can use ECN. This is due to the
feedback, which for RTP is RTCP. 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 The remainder of this memo is structured as follows. We start by
describing the conventions, definitions and acronyms used in this describing the conventions, definitions and acronyms used in this
memo in Section 2, and the design rationale and applicability in memo in Section 2, and the design rationale and applicability in
Section 3. Section 4 provides an overview of how ECN is used with Section 3. Section 4 gives an overview of how ECN is used with RTP
RTP over UDP. Then the definition of the RTCP extensions for ECN over UDP. RTCP extensions for ECN feedback are defined in Section 5,
feedback in Section 5. Then the SDP signalling extensions required and SDP signalling extensions in Section 6. The details of how ECN
are specified Section 6.Then the full details of how ECN is used with is used with RTP over UDP are defined in Section 7. In Section 8 we
RTP over UDP is defined in Section 7. In Section 8 we discuss how describe how ECN is handled in RTP translators and mixers. Section 9
RTCP ECN feedback is handled in RTP translators and mixers. discusses some implementation considerations, Section 10 lists IANA
Section 9 discusses some implementation considerations, Section 10 considerations, and Section 11 discusses security considerations.
lists IANA considerations, and Section 11 discusses the security
considerations.
2. Conventions, Definitions and Acronyms 2. Conventions, Definitions and Acronyms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC "OPTIONAL" in this document are to be interpreted as described in RFC
2119 [RFC2119]. 2119 [RFC2119].
Abbreviations Abbreviations and Definitions:
o ECN: Explicit Congestion Notification
o ECT: ECN Capable Transport
o ECN-CE: ECN Congestion Experienced
o not-ECT: Not ECN Capable Transport
This document uses the terms sender and receiver according to the
following definition:
Sender: Sender of RTP packets carrying an encoded media stream. The Sender: A sender of RTP packets carrying an encoded media stream.
sender has the possibility to effect how this transmission is The sender has the possibility to effect how this transmission is
performed. It is one end-point of the ECN control loop. performed. It is one end-point of the ECN control loop.
Receiver: A receiver of RTP packets with the intention to consume Receiver: A receiver of RTP packets with the intention to consume
the media stream in some form. It sends RTCP feedback on the the media stream. It sends RTCP feedback on the received stream.
received stream. It is the other end-point of the ECN control It is the other end-point of the ECN control loop.
loop.
Note: RTP mixers or translators that operate in such a manner that ECN Capable Host: A sender or receiver of a media stream that is
they terminate or split the ECN control loop will take on the role of capable of setting and/or processing ECN marks.
receivers or senders. This is further discussed in Section 3.2.
The meaning of the term ECN support depends on which entity between ECN Capable Transport (ECT): A transport flow where both sender and
the sender and receiver (inclusive) that is considered. We receiver are ECN capable hosts. Packets sent by an ECN Capable
distinguish between: Transport will be marked as ECT(0) or ECT(1) on transmission.
o ECN-Capable Host: Sender or receiver of media. ECN-CE: ECN Congestion Experienced mark
o ECN-Capable Transport: ECT = all ends are ECN capable hosts. ECN Capable Packets: Packets with ECN mark set to either ECT(0),
ECT(1) or ECN-CE.
o ECN-Capable Packets: Packets are either ECT or CE. Not-ECT packets: Packets that are not sent by an ECN capable
transport, and are not ECN-CE marked.
o ECN-Oblivious Relay: Router or middlebox that treats ECN-Capable ECN Oblivious Relay: A router or middlebox that treats ECN Capable
Packets no differently from Not-ECT. Packets no differently from Not-ECT packets.
o ECN-Capable Queue: Supports ECN marking of ECN-Capable Packets. ECN Capable Queue: A queue that supports ECN-CE marking of ECN-
Capable Packets to indicate congestion.
o ECN-Blocking Middlebox: Discards ECN-Capable Packets. ECN Blocking Middlebox: A middlebox that discards ECN-Capable
Packets.
o ECN-Reverting Middlebox: Changes ECN-Capable Packets to Not-ECT. ECN Reverting Middlebox: A middlebox that changes ECN-Capable
Packets to Not-ECT packets by removing the ECN mark.
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.
3. Discussion, Requirements, and Design Rationale 3. Discussion, Requirements, and Design Rationale
ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960], ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960],
and DCCP [RFC4340] transports. These are all unicast protocols which and DCCP [RFC4340] transports. These are all unicast protocols which
negotiate the use of ECN during the initial connection establishment negotiate the use of ECN during the initial connection establishment
handshake (supporting incremental deployment, and checking if ECN handshake (supporting incremental deployment, and checking if ECN
marked packets pass all middleboxes on the path). ECN Congestion marked packets pass all middleboxes on the path). ECN-CE marks are
Experienced (ECN-CE) marks are immediately echoed back to the sender immediately echoed back to the sender by the receiving end-point
by the receiving end-point using an additional bit in feedback using an additional bit in feedback messages, and the sender then
messages, and the sender then interprets the mark as equivalent to a interprets the mark as equivalent to a packet loss for congestion
packet loss for congestion control purposes. control purposes.
If RTP is run over TCP, SCTP, or DCCP, it can use the native ECN 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 support provided by those protocols. This memo does not concern
itself further with these use cases. However, RTP is more commonly itself further with these use cases. However, RTP is more commonly
run over UDP. This combination does not currently support ECN, and run over UDP. This combination does not currently support ECN, and
we observe that it has significant differences from the other we observe that it has significant differences from the other
transport protocols for which ECN has been specified. These include: transport protocols for which ECN has been specified. These include:
Signalling: RTP relies on separate signalling protocols to negotiate Signalling: RTP relies on separate signalling protocols to negotiate
parameters before a session can be created, and doesn't include an parameters before a session can be created, and doesn't include an
in-band handshake or negotiation at session set-up time (i.e. in-band handshake or negotiation at session set-up time (i.e.,
there is no equivalent to the TCP three-way handshake in RTP). there is no equivalent to the TCP three-way handshake in RTP).
Feedback: RTP does not explicitly acknowledge receipt of datagrams. Feedback: RTP does not explicitly acknowledge receipt of datagrams.
Instead, the RTP Control Protocol (RTCP) provides reception Instead, the RTP Control Protocol (RTCP) provides reception
quality feedback, and other back channel communication, for RTP quality feedback, and other back channel communication, for RTP
sessions. The feedback interval is generally on the order of sessions. The feedback interval is generally on the order of
seconds, rather than once per network RTT (although the RTP/AVPF seconds, rather than once per network RTT (although the RTP/AVPF
profile [RFC4585] allows more rapid feedback in most cases). profile [RFC4585] allows more rapid feedback in most cases). RTCP
is also very much oriented around counting packets, which makes
byte counting congestion algorithms difficult to utilize.
Congestion Response: While it is possible to adapt the transmission Congestion Response: While it is possible to adapt the transmission
of many audio/visual streams in response to network congestion, of many audio/visual streams in response to network congestion,
and such adaptation is required by [RFC3550], the dynamics of the and such adaptation is required by [RFC3550], the dynamics of the
congestion response may be quite different to those of TCP or congestion response may be quite different to those of TCP or
other transport protocols. other transport protocols.
Middleboxes: The RTP framework explicitly supports the concept of Middleboxes: The RTP framework explicitly supports the concept of
mixers and translators, which are middleboxes that are involved in mixers and translators, which are middleboxes that are involved in
media transport functions. media transport functions.
Multicast: RTP is explicitly a group communication protocol, and was Multicast: RTP is explicitly a group communication protocol, and was
designed from the start to support IP multicast (primarily ASM, designed from the start to support IP multicast (primarily Any
although a recent extension supports SSM with unicast feedback Source Multicast (ASM) [RFC1112], although a recent extension
[RFC5760]). supports Source Specific Multicast (SSM) [RFC3569] with unicast
feedback [RFC5760]).
Application Awareness: ECN support via TCP, DCCP, and SCTP constrain Application Awareness: When ECN support is provided within the
the awareness and reaction to packet loss within those protocols. transport protocol, the ability of the application to react to
By adding support of ECN through RTCP, the application is made congestion is limited, since it has little visibility into the
aware of packet loss and may choose one or more approaches in transport layer. By adding support of ECN to RTP using RTCP
response to that loss. feedback, the application is made aware of congestion, allowing a
wider range of reactions in response to that loss.
Counting vs Detecting Congestion: TCP and the protocols derived from Counting vs Detecting Congestion: TCP and the protocols derived from
it are mainly designed to respond the same whether they experience it are mainly designed to respond the same whether they experience
a burst of congestion indications within one RTT or just one. a burst of congestion indications within one RTT or just one.
Whereas real-time applications may be concerned with the amount of Whereas real-time applications may be concerned with the amount of
congestion experienced, whether it is distributed smoothly or in congestion experienced, whether it is distributed smoothly or in
bursts. When feedback of ECN was added to TCP [RFC3168], the bursts. When feedback of ECN was added to TCP [RFC3168], the
receiver was designed to flip the echo congestion experienced receiver was designed to flip the echo congestion experienced
(ECE) flag to 1 for a whole RTT then flop it back to zero. (ECE) flag to 1 for a whole RTT then flop it back to zero.
Whereas ECN feedback in RTCP will need to report a count of how Whereas ECN feedback in RTCP will need to report a count of how
skipping to change at page 8, line 11 skipping to change at page 7, line 48
occur, can potentially reduce unnecessary queueing delays in routers, occur, can potentially reduce unnecessary queueing delays in routers,
lowering the round-trip time and benefiting interactive applications lowering the round-trip time and benefiting interactive applications
of RTP, such as voice telephony. of RTP, such as voice telephony.
3.1. Requirements 3.1. Requirements
Considering ECN, transport protocols supporting ECN, and RTP based Considering ECN, transport protocols supporting ECN, and RTP based
applications one can create a set of requirements that must be 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. satisfied to at least some degree if ECN is to used by RTP over UDP.
o REQ 1: A mechanism MUST negotiate and initiate the usage of ECN o REQ 1: A mechanism MUST exist to negotiate and initiate the use of
for RTP/UDP/IP sessions so that an RTP sender will not send ECN for RTP/UDP/IP sessions so that an RTP sender will not send
packets with ECT in the IP header unless it knows all potential packets with ECT in the IP header unless it knows that all
receivers will understand any CE indications they might receive. potential receivers will understand any CE indications they might
receive.
o REQ 2: A mechanism MUST feedback the reception of any packets that o REQ 2: A mechanism MUST exist to feed back the reception of any
are ECN-CE marked to the packet sender packets that are ECN-CE marked to the packet sender.
o REQ 3: Provided mechanism SHOULD minimise the possibility for o REQ 3: The provided mechanism SHOULD minimise the possibility of
cheating cheating (either by the sender or receiver).
o REQ 4: Some detection and fallback mechanism SHOULD exist to avoid o REQ 4: Some detection and fallback mechanism SHOULD exist to avoid
loss of communication due to the attempted usage of ECN in case an loss of communication due to the attempted usage of ECN in case an
intermediate node clears ECT or drops packets that are ECT marked. intermediate node clears ECT or drops packets that are ECT marked.
o REQ 5: Negotiation of ECN SHOULD NOT significantly increase the o REQ 5: Negotiation of ECN SHOULD NOT significantly increase the
time taken to negotiate and set-up the RTP session (an extra RTT 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 before the media can flow is unlikely to be acceptable for some
use cases). use cases).
o REQ 6: Negotiation of ECN SHOULD NOT cause media clipping at the o REQ 6: Negotiation of ECN SHOULD NOT cause media clipping at the
start of a session. start of a session.
The following sections describes how these requirements can be meet The following sections describes how these requirements can be met
for RTP over UDP. for RTP over UDP.
3.2. Applicability 3.2. Applicability
The use of ECN with RTP over UDP is dependent on negotiation of ECN 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 capability between the sender and receiver(s), and validation of ECN
support in all elements of the network path(s) traversed. RTP is support in all elements of the network path(s) traversed. RTP is
used in a heterogeneous range of network environments and topologies, used in a heterogeneous range of network environments and topologies,
with various different signalling protocols, all of which need to be with various different signalling protocols. The mechanisms defined
verified to support ECN before it can be used. 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 intended to use ECN with RTP 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 to track all participants in the RTP session the sub-sampling of the
group membership as specified by "Sampling of the Group Membership in group membership as specified by "Sampling of the Group Membership in
RTP" [RFC2762] MUST NOT be used. RTP" [RFC2762] MUST NOT be used.
The usage of ECN is further dependent on a capability of the RTP The use of ECN is further dependent on a capability of the RTP media
media flow to react to congestion signalled by ECN marked packets. flow to react to congestion signalled by ECN marked packets.
Depending on the application, media codec, and network topology, this Depending on the application, media codec, and network topology, this
adaptation can occur in various forms and at various nodes. As an adaptation can occur in various forms and at various nodes. As an
example, the sender can change the media encoding, or the receiver example, the sender can change the media encoding, or the receiver
can change the subscription to a layered encoding, or either reaction can change the subscription to a layered encoding, or either reaction
can be accomplished by a transcoding middlebox. RFC 5117 identifies can be accomplished by a transcoding middlebox. RFC 5117 identifies
seven topologies in which RTP sessions may be configured, and which seven topologies in which RTP sessions may be configured, and which
may affect the ability to use ECN: may affect the ability to use ECN:
Topo-Point-to-Point: This is a standard unicast flow. ECN may be Topo-Point-to-Point: This is a standard unicast flow. ECN may be
used with RTP in this topology in an analogous manner to its use used with RTP in this topology in an analogous manner to its use
skipping to change at page 9, line 30 skipping to change at page 9, line 22
RTCP feedback, or a source specific multicast (SSM) group RTCP feedback, or a source specific multicast (SSM) group
[RFC4607] with a single sender and unicast RTCP feedback from [RFC4607] with a single sender and unicast RTCP feedback from
receivers. RTCP is designed to scale to large group sizes while receivers. RTCP is designed to scale to large group sizes while
avoiding feedback implosion (see Section 6.2 of [RFC3550], avoiding feedback implosion (see Section 6.2 of [RFC3550],
[RFC4585], and [RFC5760]), and can be used by a sender to [RFC4585], and [RFC5760]), and can be used by a sender to
determine if all its receivers, and the network paths to those determine if all its receivers, and the network paths to those
receivers, support ECN (see Section 7.2). It is somewhat more receivers, support ECN (see Section 7.2). It is somewhat more
difficult to determine if all network paths from all senders to difficult to determine if all network paths from all senders to
all receivers support ECN. Accordingly, we allow ECN to be used all receivers support ECN. Accordingly, we allow ECN to be used
by an RTP sender using multicast UDP provided the sender has by an RTP sender using multicast UDP provided the sender has
verified that the paths to all known receivers support ECN, and verified that the paths to all its known receivers support ECN,
irrespective of whether the paths from other senders to their and irrespective of whether the paths from other senders to their
receivers support ECN. "all its known receivers" are all the SSRCs receivers support ECN ("all its known receivers" are all the SSRCs
that the RTP sender has received RTP or RTCP from the last five that the RTP sender has received RTP or RTCP from the last five
reporting intervals, i.e. they are not timed out. Note that group reporting intervals, i.e., they have not timed out). Note that
membership may change during the lifetime of a multicast RTP group membership may change during the lifetime of a multicast RTP
session, potentially introducing new receivers that are not ECN session, potentially introducing new receivers that are not ECN
capable or have a path that doesn't support ECN. Senders must use capable or have a path that doesn't support ECN. Senders must use
the mechanisms described in Section 7.4 to monitor that all the mechanisms described in Section 7.4 to monitor that all
receivers continue to support ECN, and they need to fallback to receivers continue to support ECN, and they need to fallback to
non-ECN use if any senders do not. non-ECN use if any senders do not.
Topo-Translator: An RTP translator is an RTP-level middlebox that is Topo-Translator: An RTP translator is an RTP-level middlebox that is
invisible to the other participants in the RTP session (although invisible to the other participants in the RTP session (although
it is usually visible in the associated signalling session). it is usually visible in the associated signalling session).
There are two types of RTP translator: those do not modify the There are two types of RTP translator: those that do not modify
media stream, and are concerned with transport parameters, for the media stream, and are concerned with transport parameters, for
example a multicast to unicast gateway; and those that do modify example a multicast to unicast gateway; and those that do modify
the media stream, for example transcoding between different media the media stream, for example transcoding between different media
codecs. A single RTP session traverses the translator, and the codecs. A single RTP session traverses the translator, and the
translator must rewrite RTCP messages passing through it to match translator must rewrite RTCP messages passing through it to match
the changes it makes to the RTP data packets. A legacy, ECN- the changes it makes to the RTP data packets. A legacy, ECN-
unaware, RTP translator is expected to ignore the ECN bits on unaware, RTP translator is expected to ignore the ECN bits on
received packets, and to set the ECN bits to not-ECT when sending received packets, and to set the ECN bits to not-ECT when sending
packets, so causing ECN negotiation on the path containing the packets, so causing ECN negotiation on the path containing the
translator to fail (any new RTP translator that does not wish to translator to fail (any new RTP translator that does not wish to
support ECN may do so similarly). An ECN aware RTP translator may support ECN may do so similarly). An ECN aware RTP translator may
act in one of three ways: act in one of three ways:
* If the translator does not modify the media stream, it should * If the translator does not modify the media stream, it should
copy the ECN bits unchanged from the incoming to the outgoing copy the ECN bits unchanged from the incoming to the outgoing
datagrams, unless it is overloaded and experiencing congestion, datagrams, unless it is overloaded and experiencing congestion,
in which case it may mark the outgoing datagrams with an ECN-CE in which case it may mark the outgoing datagrams with an ECN-CE
mark. Such a translator passes RTCP feedback unchanged. mark. Such a translator passes RTCP feedback unchanged. See
Section 8.1.
* If the translator modifies the media stream to combine or split * If the translator modifies the media stream to combine or split
RTP packets, but does not otherwise transcode the media, it RTP packets, but does not otherwise transcode the media, it
must manage the ECN bits in a way analogous to that described must manage the ECN bits in a way analogous to that described
in Section 5.3 of [RFC3168]: if an ECN marked packet is split in Section 5.3 of [RFC3168], see Section 8.2 for details.
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. When RTCP ECN feedback packets (Section 5) are
received, they must be rewritten to match the modifications
made to the media stream (see Section 8.1).
* If the translator is a media transcoder, the output RTP media * If the translator is a media transcoder, or otherwise modifies
stream may have radically different characteristics than the the content of the media stream, the output RTP media stream
input RTP media stream. Each side of the translator must then may have radically different characteristics than the input RTP
be considered as a separate transport connection, with its own media stream. Each side of the translator must then be
ECN processing. This requires the translator interpose itself considered as a separate transport connection, with its own ECN
into the ECN negotiation process, effectively splitting the processing. This requires the translator interpose itself into
the ECN negotiation process, effectively splitting the
connection into two parts with their own negotiation. Once connection into two parts with their own negotiation. Once
negotiation has been completed, the translator must generate negotiation has been completed, the translator must generate
RTCP ECN feedback back to the source based on its own RTCP ECN feedback back to the source based on its own
reception, and must respond to RTCP ECN feedback received from reception, and must respond to RTCP ECN feedback received from
the receiver(s) (see Section 8.2). the receiver(s) (see Section 8.3).
It is recognised that ECN and RTCP processing in an RTP translator It is recognised that ECN and RTCP processing in an RTP translator
that modifies the media stream is non-trivial. that modifies the media stream is non-trivial.
Topo-Mixer: A mixer is an RTP-level middlebox that aggregates Topo-Mixer: A mixer is an RTP-level middlebox that aggregates
multiple RTP streams, mixing them together to generate a new RTP multiple RTP streams, mixing them together to generate a new RTP
stream. The mixer is visible to the other participants in the RTP stream. The mixer is visible to the other participants in the RTP
session, and is also usually visible in the associated signalling session, and is also usually visible in the associated signalling
session. The RTP flows on each side of the mixer are treated session. The RTP flows on each side of the mixer are treated
independently for ECN purposes, with the mixer generating its own independently for ECN purposes, with the mixer generating its own
RTCP ECN feedback, and responding to ECN feedback for data it RTCP ECN feedback, and responding to ECN feedback for data it
sends. Since connections are treated independently, it would seem sends. Since unicast transport between the mixer and any end-
reasonable to allow the transport on one side of the mixer to use point are treated independently, it would seem reasonable to allow
ECN, while the transport on the other side of the mixer is not ECN the transport on one side of the mixer to use ECN, while the
capable, if this is desired. transport on the other side of the mixer is not ECN capable, if
this is desired. See Section 8.4 for details in how mixers should
process ECN.
Topo-Video-switch-MCU: A video switching MCU receives several RTP Topo-Video-switch-MCU: A video switching MCU receives several RTP
flows, but forwards only one of those flows onwards to the other flows, but forwards only one of those flows onwards to the other
participants at a time. The flow that is forwarded changes during participants at a time. The flow that is forwarded changes during
the session, often based on voice activity. Since only a subset the session, often based on voice activity. Since only a subset
of the RTP packets generated by a sender are forwarded to the of the RTP packets generated by a sender are forwarded to the
receivers, a video switching MCU can break ECN negotiation (the receivers, a video switching MCU can break ECN negotiation (the
success of the ECN negotiation may depend on the voice activity of success of the ECN negotiation may depend on the voice activity of
the participant at the instant the negotiation takes place - shout the participant at the instant the negotiation takes place - shout
if you want ECN). It also breaks congestion feedback and if you want ECN). It also breaks congestion feedback and
response, since RTP packets are dropped by the MCU depending on response, since RTP packets are dropped by the MCU depending on
voice activity rather than network congestion. This topology is voice activity rather than network congestion. This topology is
widely used in legacy products, but is NOT RECOMMENDED for new widely used in legacy products, but is NOT RECOMMENDED for new
implementations and cannot be used with ECN. implementations and SHALL NOT be used with ECN.
Topo-RTCP-terminating-MCU: In this scenario, each participant runs Topo-RTCP-terminating-MCU: In this scenario, each participant runs
an RTP point-to-point session between itself and the MCU. Each of an RTP point-to-point session between itself and the MCU. Each of
these sessions is treated independently for the purposes of ECN these sessions is treated independently for the purposes of ECN
and RTCP feedback, potentially with some using ECN and some not. and RTCP feedback, potentially with some using ECN and some not.
Topo-Asymmetric: It is theoretically possible to build a middlebox Topo-Asymmetric: It is theoretically possible to build a middlebox
that is a combination of an RTP mixer in one direction and an RTP that is a combination of an RTP mixer in one direction and an RTP
translator in the other. To quote RFC 5117 "This topology is so translator in the other. To quote RFC 5117 "This topology is so
problematic and it is so easy to get the RTCP processing wrong, problematic and it is so easy to get the RTCP processing wrong,
skipping to change at page 12, line 15 skipping to change at page 11, line 50
and receiver. and receiver.
3.3. Interoperability 3.3. Interoperability
The interoperability requirements for this specification are that The interoperability requirements for this specification are that
there is at least one common interoperability point for all there is at least one common interoperability point for all
implementations. Since initialization using RTP and RTCP is the one implementations. Since initialization using RTP and RTCP is the one
method that works in all cases, although is not optimal for all method that works in all cases, although is not optimal for all
usages, it is selected as mandatory to implement this initialisation usages, it is selected as mandatory to implement this initialisation
method. This method requires both the RTCP XR extension and the ECN method. This method requires both the RTCP XR extension and the ECN
feedback format, which requires the RTP AVPF profile to ensure timely feedback format, which requires the RTP/AVPF profile to ensure timely
feedback. feedback.
When one considers all the uses of ECN for RTP it is clear that When one considers all the uses of ECN for RTP it is clear that there
congestion control mechanisms that are receiver driven only exist congestion control mechanisms that are receiver driven only
(Section 7.3.3) do not require timely feedback of congestion events. (Section 7.3.3). These congestion control mechanism do not require
If such a congestion control mechanism is combined with an timely feedback of congestion events to the sender. If such a
initialization method that also doesn't require timely feedback using congestion control mechanism is combined with an initialization
RTCP, like the leap of faith or the ICE based method then neither the method that also doesn't require timely feedback using RTCP, like the
ECN feedback format nor AVPF is strictly needed. However, we would leap of faith or the ICE based method then neither the ECN feedback
like to point out that fault detection can be improved by using format nor the RTP/AVPF profile would appear to be needed. However,
receiver side detection (Section 7.4.1) and early reporting of such fault detection can be greatly improved by using receiver side
cases using the ECN feedback mechanism. detection (Section 7.4.1) and early reporting of such cases using the
ECN feedback mechanism.
For interoperability we do mandate the implementation of AVPF, with For interoperability we mandate the implementation of the RTP/AVPF
both RTCP extensions and the necessary signalling to support a common profile, with both RTCP extensions and the necessary signalling to
operations mode. This specification will still recommend the usage support a common operations mode. This specification recommends the
of AVPF in all cases as negotiation of the common interoperability use of RTP/AVPF in all cases as negotiation of the common
point requires AVPF, and mixed negotiation of AVP and AVPF depending interoperability point requires RTP/AVPF, mixed negotiation of RTP/
on other SDP attributes in the same media block are difficult and the AVP and RTP/AVPF depending on other SDP attributes in the same media
fact that fault detection can be improved when using AVPF. The use block is difficult, and the fact that fault detection can be improved
of the ECN feedback format is also recommended but cases where there when using RTP/AVPF.
is no requirement for timely feedback will be noted. The term "no
timely feedback required" will be used to indicate usage that employs The use of the ECN feedback format is also recommended but cases
this specification in combination with receiver driven congestion where its usage is not required due to no need for timely feedback,
control, and initialization methods that do not require timely that will be explicitly noted in the specification text. The term
feedback, i.e. currently leap of faith and ICE based. We also note "no timely feedback required" will be used to indicate usage that
that any receiver driven congestion control solution that still employs this specification in combination with receiver driven
congestion control, and initialization methods that do not require
timely feedback, i.e. currently leap of faith and ICE based. We also
note that any receiver driven congestion control solution that still
requires RTCP for signalling of any adaptation information to the requires RTCP for signalling of any adaptation information to the
sender will still require AVPF. sender will still require RTP/AVPF for timeliness.
4. Overview of Use of ECN with RTP/UDP/IP 4. Overview of Use of ECN with RTP/UDP/IP
The solution for using ECN with RTP over UDP/IP consists of four The solution for using ECN with RTP over UDP/IP consists of four
different pieces that together make the solution work: different pieces that together make the solution work:
1. Negotiation of the capability to use ECN with RTP/UDP/IP 1. Negotiation of the capability to use ECN with RTP/UDP/IP
2. Initiation and initial verification of ECN capable transport 2. Initiation and initial verification of ECN capable transport
3. Ongoing use of ECN within an RTP session 3. Ongoing use of ECN within an RTP session
4. Handling of dynamic groups through failure detection, 4. Handling of dynamic behavior through failure detection,
verification and fallback verification and fallback
The solution includes a new SDP attribute (Section 6.1), the Before an RTP session can be created, a signalling protocol is used
definition of new extensions to RTCP (Section 5) and STUN to discover the other participants and negotiate or configure session
(Section 7.2.2). parameters (see Section 7.1). One of the parameters that must be
agreed is the capability of a participant to support ECN. Note that
Before an RTP session can be created, a signalling protocol is often all participants having the capability of supporting ECN does not
used to discover the other participants and negotiate session necessarily imply that ECN is usable in an RTP session, since there
parameters (see Section 7.1). At the minimum a signalling protocol may be middleboxes on the path between the participants which don't
is used to configure RTP session participants through a declarative pass ECN-marked packets (for example, a firewall that blocks traffic
method. One of the parameters that can be negotiated is the with the ECN bits set). This document defines the information that
capability of a participant to support ECN functionality, or needs to be negotiated, and provides a mapping to SDP for use in both
otherwise. Note that all participants having the capability of declarative and offer/answer contexts.
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 ECN When a sender joins a session for which all participants claim to
capability, it must verify if that capability is usable. There are support ECN, it must verify if that support is usable. There are
three ways in which this verification may be done (Section 7.2): three ways in which this verification can be done:
o The sender may generate a (small) subset of its RTP data packets o The sender may generate a (small) subset of its RTP data packets
with the ECN field set to ECT(0) or ECT(1). Each receiver will with the ECN field set to ECT(0) or ECT(1). Each receiver will
then send an RTCP feedback packet indicating the reception of the then send an RTCP feedback packet indicating the reception of the
ECT marked RTP packets. Upon reception of this feedback from each ECT marked RTP packets. Upon reception of this feedback from each
receiver it knows of, the sender can consider ECN functional for receiver it knows of, the sender can consider ECN functional for
its traffic. Each sender does this verification independently of its traffic. Each sender does this verification independently.
each other. If a new receiver joins an existing session it will When a new receiver joins an existing RTP session, it will send
reveal whether or not it supports ECN when it sends its first RTCP RTCP reports in the usual manner. If those RTCP reports include
report to each source. If the RTCP report includes ECN ECN information, verification will have succeeded and sources can
information, verification will have succeeded and sources can
continue to send ECT packets. If not, verification fails and each continue to send ECT packets. If not, verification fails and each
sender MUST stop using ECN. sender MUST stop using ECN (see Section 7.2.1 for details).
o Alternatively, ECN support can be verified during an initial end- o Alternatively, ECN support can be verified during an initial end-
to-end STUN exchange (for example, as part of ICE connection to-end STUN exchange (for example, as part of ICE connection
establishment). After having verified connectivity without ECN establishment). After having verified connectivity without ECN
capability an extra STUN exchange, this time with the ECN field capability an extra STUN exchange, this time with the ECN field
set to ECT(0) or ECT(1), is performed. If successful the path's set to ECT(0) or ECT(1), is performed on the candidate path that
capability to convey ECN marked packets is verified. A new STUN is about to be used. If successful the path's capability to
attribute is defined to convey feedback that the ECT marked STUN convey ECN marked packets is verified. A new STUN attribute is
request was received (see Section 7.2.2), along with an ICE defined to convey feedback that the ECT marked STUN request was
signalling option (Section 6.4). received (see Section 7.2.2), along with an ICE signalling option
(Section 6.4) to indicate that the check is to be performed.
o Thirdly, the sender may make a leap of faith that ECN will work. o Thirdly, the sender may make a leap of faith that ECN will work.
This is only recommended for applications that know they are This is only recommended for applications that know they are
running in controlled environments where ECN functionality has running in controlled environments where ECN functionality has
been verified through other means. In this mode it is assumed been verified through other means. In this mode it is assumed
that ECN works, and the system reacts to failure indicators if the that ECN works, and the system reacts to failure indicators if the
assumption proved wrong. The use of this method relies on a high assumption proved wrong. The use of this method relies on a high
confidence that ECN operation will be successful, or an confidence that ECN operation will be successful, or an
application where failure is not serious. The impact on the application where failure is not serious. The impact on the
network and other users must be considered when making a leap of network and other users must be considered when making a leap of
faith, so there are limitations on when this method is allowed. faith, so there are limitations on when this method is allowed
(see Section 7.2.3).
The first mechanism, using RTP with RTCP feedback, has the advantage The first mechanism, using RTP with RTCP feedback, has the advantage
of working for all RTP sessions, but the disadvantages of potential of working for all RTP sessions, but the disadvantages of potential
clipping if ECN marked RTP packets are discarded by middleboxes, and clipping if ECN marked RTP packets are discarded by middleboxes, and
slow verification of ECN support. The STUN-based mechanism is faster slow verification of ECN support. The STUN-based mechanism is faster
to verify ECN support, but only works in those scenarios supported by 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, end-to-end STUN, such as within an ICE exchange. The third one,
leap-of-faith, has the advantage of avoiding additional tests or leap-of-faith, has the advantage of avoiding additional tests or
complexities and enabling ECN usage from the first media packet. The complexities and enabling ECN usage from the first media packet. The
downside is that if the end-to-end path contains middleboxes that do 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 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 worst case, all media could be lost if a middlebox that discards ECN
marked packets is present. A less severe effect, but still requiring marked packets is present. A less severe effect, but still requiring
reaction, is the presence of a middlebox that re-marks ECT marked reaction, is the presence of a middlebox that re-marks ECT marked
packets to non-ECT, possibly marking packets with a CE mark as non- packets to non-ECT, possibly marking packets with a CE mark as non-
ECT. This can force the network into heavy congestion due to non- ECT. This could result in increased levels of congestion due to non-
responsiveness, and seriously impact media quality. 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 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, a sender marks all its RTP packets as ECT packets, while
receivers rapidly feedback any CE marks to the sender using RTCP in receivers rapidly feed back reports on any ECN-CE marks to the sender
RTP/AVPF immediate or early feedback mode, unless no timely feedback using RTCP in RTP/AVPF immediate or early feedback mode, unless no
is required. An RTCP feedback report is sent as soon as possible timely feedback is required. Each feedback report indicates the
according to the transmission rules for feedback that are in place. receipt of new CE marks since the last ECN feedback packet, and also
This feedback report indicates the receipt of new CE marks since the counts the total number of CE marked packets as a cumulative sum.
last ECN feedback packet, and also counts the total number of CE This is the mechanism to provide the fastest possible feedback to
marked packets through a cumulative sum. This is the mechanism to senders about CE marks. On receipt of a CE marked packet, the system
provide the fastest possible feedback to senders about CE marks. On must react to congestion as-if packet loss has been reported.
receipt of a CE marked packet, the system must react to congestion Section 7.3 describes the ongoing use of ECN within an RTP session.
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, therefore an This rapid feedback is not optimised for reliability, so another
additional procedure, the RTCP ECN summary reports, is used to ensure mechanism, RTCP XR ECN summary reports, is used to ensure more
more reliable, but less timely, reporting of the ECN information. reliable, but less timely, reporting of the ECN information. The ECN
The ECN summary report contains the same information as the ECN summary report contains the same information as the ECN feedback
feedback format, only packed differently for better efficiency with format, only packed differently for better efficiency with reports
reports for many sources. It is sent in a compound RTCP packet, for many sources. It is sent in a compound RTCP packet, along with
along with regular RTCP reception reports. By using cumulative regular RTCP reception reports. By using cumulative counters for
counters for seen CE, ECT, not-ECT, and packet loss the sender can observed CE, ECT, not-ECT, packet duplication, and packet loss the
determine what events have happened since the last report, sender can determine what events have happened since the last report,
independently of any RTCP packets having been lost. independently of any RTCP packets having been lost.
RTCP traffic MUST NOT be ECT marked for the following reason. ECT RTCP reports MUST NOT be ECT marked, since ECT marked traffic may be
marked traffic may be dropped if the path is not ECN compliant. As dropped if the path is not ECN compliant. RTCP is used to provide
RTCP is used to provide feedback about what has been transmitted and feedback about what has been transmitted and what ECN markings that
what ECN markings that are received, it is important that these are are received, so it is important that it is received in cases when
received in cases when ECT marked traffic is not getting through. ECT marked traffic is not getting through.
There are numerous reasons why the path the RTP packets take from the There are numerous reasons why the path the RTP packets take from the
sender to the receiver may change, e.g., mobility, link failure sender to the receiver may change, e.g., mobility, link failure
followed by re-routing around it. Such an event may result in the 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- packet being sent through a node that is ECN non-compliant, thus re-
marking or dropping packets with ECT set. To prevent this from marking or dropping packets with ECT set. To prevent this from
impacting the application for longer than necessary, the operation of impacting the application for longer than necessary, the operation of
ECN is constantly monitored by all senders. Both the RTCP ECN ECN is constantly monitored by all senders (Section 7.4). Both the
summary reports and the ECN feedback packets allow the sender to RTCP XR ECN summary reports and the ECN feedback packets allow the
compare the number of ECT(0), ECT(1), and non-ECT marked packets sender to compare the number of ECT(0), ECT(1), and non-ECT marked
received with the number that were sent, while also reporting CE packets received with the number that were sent, while also reporting
marked and lost packets. If these numbers do not agree, it can be 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 inferred that the path does not reliably pass ECN-marked packets. A
(Section 7.4.2 discusses how to interpret the different cases). A
sender detecting a possible ECN non-compliance issue should then stop sender detecting a possible ECN non-compliance issue should then stop
sending ECT marked packets to determine if that allows the packets to sending ECT marked packets to determine if that allows the packets to
be correctly delivered. If the issues can be connected to ECN, then be correctly delivered. If the issues can be connected to ECN, then
ECN usage is suspended and possibly also re-negotiated. ECN usage is suspended.
5. RTCP Extensions for ECN feedback 5. RTCP Extensions for ECN feedback
This documents defines two different RTCP extensions: one RTP/AVPF This memo defines two new RTCP extensions: one RTP/AVPF [RFC4585]
[RFC4585] transport layer feedback format for urgent ECN information, transport layer feedback format for urgent ECN information, and one
and one RTCP XR [RFC3611] ECN summary report block type for regular RTCP XR [RFC3611] ECN summary report block type for regular reporting
reporting of the ECN marking information. The full definition of of the ECN marking information.
these extensions usage as part of the complete solution is laid out
in Section 7.
5.1. RTP/AVPF Transport Layer ECN Feedback packet 5.1. RTP/AVPF Transport Layer ECN Feedback packet
This RTP/AVPF transport layer feedback format is intended for usage This RTP/AVPF transport layer feedback format is intended for use in
in AVPF early or immediate feedback modes when information needs to RTP/AVPF early or immediate feedback modes when information needs to
urgently reach the sender. Thus its main use is to report on urgently reach the sender. Thus its main use is to report on
reception of an ECN-CE marked RTP packet so that the sender may reception of an ECN-CE marked RTP packet so that the sender may
perform congestion control, or to speed up the initiation procedures perform congestion control, or to speed up the initiation procedures
by rapidly reporting that the path can support ECN-marked traffic. by rapidly reporting that the path can support ECN-marked traffic.
The feedback format is also defined with reduced size RTCP [RFC5506] The feedback format is also defined with reduced size RTCP [RFC5506]
in mind, where RTCP feedback packets may be sent without accompanying in mind, where RTCP feedback packets may be sent without accompanying
Sender or Receiver Reports that would contain the Extended Highest Sender or Receiver Reports that would contain the Extended Highest
Sequence number and the accumulated number of packet losses. Both Sequence number and the accumulated number of packet losses. Both
are important for ECN to verify functionality and keep track of when are important for ECN to verify functionality and keep track of when
CE marking does occur. CE marking does occur.
The RTP/AVPF transport layer feedback packet starts with the common The RTP/AVPF transport layer feedback packet starts with the common
header defined by the RTP/AVPF profile [RFC4585] which is reproduced header defined by the RTP/AVPF profile [RFC4585] which is reproduced
here for the reader's information: 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
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 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 | PT=RTPFB=205 | length | |V=2|P| FMT=TBA1| PT=RTPFB=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source | | SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) : : Feedback Control Information (FCI) :
: : : :
Figure 1: RTP/AVPF Common Packet Format for Feedback Messages Figure 1: RTP/AVPF Common Packet Format for Feedback Messages
From Figure 1 it can be determined the identity of the feedback
provider and for which RTP packet sender it applies. Below is the
feedback information format defined that is inserted as FCI for this
particular feedback messages that is identified with an FMT value =
[TBA1].
0 1 2 3 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 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 | Lost packets counter | | Extended Highest Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Counter | not-ECT Counter | | ECT (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter | ECT (1) Counter | | ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Packet Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ECN Feedback Format Figure 2: ECN Feedback Report Format
The FCI information for the ECN Feedback format (Figure 2) are the The ECN Feedback Report contains the following fields:
following:
Extended Highest Sequence Number: The least significant 20-bits from Extended Highest Sequence Number: The 32-bit Extended highest
an Extended highest sequence number received value as defined by sequence number received, as defined by [RFC3550]. Indicates the
[RFC3550]. Used to indicate for which packet this report is valid highest RTP sequence number to which this report relates.
up to.
Lost Packets Counter: The cumulative number of RTP packets that the ECT(0) Counter: The 32-bit cumulative number of RTP packets with
receiver expected to receive from this SSRC, minus the number of ECT(0) received from this SSRC.
packets it actually received. This is the same as the cumulative
number of packets lost defined in Section 6.4.1 of [RFC3550] ECT(1) Counter: The 32-bit cumulative number of RTP packets with
except represented in 12-bit signed format, compared to 24-bit in ECT(1) received from this SSRC.
RTCP SR or RR packets. As with the equivalent value in RTCP SR or
RR packets, note that packets that arrive late are not counted as
lost, and the loss may be negative if there are duplicates.
CE Counter: The cumulative number of RTP packets received from this CE Counter: The cumulative number of RTP packets received from this
SSRC since the receiver joined the RTP session that were ECN-CE SSRC since the receiver joined the RTP session that were ECN-CE
marked. The receiver should keep track of this value using a marked, including ECN-CE marks in any duplicate packets. The
local representation that is longer than 16-bits, and only include receiver should keep track of this value using a local
the 16-bits with least significance. In other words, the field representation that is at least 32-bits, and only include the 16-
will wrap if more than 65535 packets has been received. bits with least significance. In other words, the field will wrap
if more than 65535 packets has been received.
ECT(0) Counter: The cumulative number of RTP packets received from not-ECT Counter: The cumulative number of RTP packets received from
this SSRC since the receiver joined the RTP session that had an this SSRC since the receiver joined the RTP session that had an
ECN field value of ECT(0). The receiver should keep track of this ECN field value of not-ECT. The receiver should keep track of
value using a local representation that is longer than 16-bits, this value using a local representation that is at least 32-bits,
and only include the 16-bits with least significance. In other and only include the 16-bits with least significance. In other
words, the field will wrap if more than 65535 packets have been words, the field will wrap if more than 65535 packets have been
received. received.
ECT(1) Counter: The cumulative number of RTP packets received from Lost Packets Counter: The cumulative number of RTP packets that the
this SSRC since the receiver joined the RTP session that had an receiver expected to receive minus the number of packets it
ECN field value of ECT(1). The receiver should keep track of this actually received that are not a duplicate of an already received
value using a local representation that is longer than 16-bits, packet, from this SSRC since the receiver joined the RTP session.
and only include the 16-bits with least significance. In other Note that packets that arrive late are not counted as lost. The
words, the field will wrap if more than 65535 packets have been receiver should keep track of this value using a local
received. representation that is at least 32-bits, and only include the 16-
bits with least significance. In other words, the field will wrap
if more than 65535 packets have been received.
not-ECT Counter: The cumulative number of RTP packets received from Duplication Counter: The cumulative number of RTP packets received
this SSRC since the receiver joined the RTP session that had an that are a duplicate of an already received packet from this SSRC
ECN field value of not-ECT. The receiver should keep track of since the receiver joined the RTP session. The receiver should
this value using a local representation that is longer than 16- keep track of this value using a local representation that is at
bits, and only include the 16-bits with least significance. In least 32-bits, and only include the 16-bits with least
other words, the field will wrap if more than 65535 packets have significance. In other words, the field will wrap if more than
been received. 65535 packets have been received.
Each FCI block reports on a single source (SSRC). Multiple sources All fields in the ECN Feedback Report are unsigned integers in
can be reported by including multiple RTCP feedback messages in an network byte order. Each ECN Feedback Report corresponds to a single
compound RTCP packet. The AVPF common header indicates both the RTP source (SSRC). Multiple sources can be reported by including
sender of the feedback message and on which stream it relates to. multiple ECN Feedback Reports packets in an compound RTCP packet.
The counters SHALL be initiated to 0 for a new receiver. This to The counters SHALL be initiated to 0 for each new SSRC received.
enable detection of CE or Packet loss already on the initial report This to enable detection of CE or Packet loss already on the initial
from a specific participant. report from a specific participant.
The Extended Highest sequence number and packet loss fields are both The usage of at least 32-bit counters allows even extremely high
truncated in comparison to the RTCP SR or RR versions. This is to packet volume applications to not have wrapping of counters within
save bits as the representation is redundant unless reduced size RTCP any timescale close to the reporting intervals. However, 32-bits are
is used in such a way that only feedback packets are transmitted, not sufficiently large to disregard the fact that wrappings may
with no SR or RR in the compound RTCP packet. Due to that fact happen during the life time of a long-lived RTP session. Thus
regular RTCP reporting will include the longer versions of the fields handling of wrapping of these counters MUST be supported. It is
and there will be less of an issue with wrapping unless the packet recommended that implementations uses local representation of these
rate of the application is so high that the fields will wrap within a counters that are longer than 32-bits to enable easy handling of
regular RTCP reporting interval. In that case the feedback packet wraps.
will need to be sent in a compound packet together with the SR or RR
packet.
There is an issue with packet duplication in relation to the packet There is a difference in packet duplication reports between the
loss counter. If one avoids holding state for which sequence number packet loss counter that is defined in the Receiver Report Block
has been received then the way one can count loss is to count the [RFC3550] and that defined here. To avoid holding state for what RTP
number of received packets and compare that to the number of packets sequence numbers have been received, [RFC3550] specifies that one can
expected. As a result a packet duplication can hide a packet loss. count packet loss by counting the number of received packets and
If a receiver is tracking the sequence numbers actually received and comparing it to the number of packets expected. As a result a packet
suppresses duplicates it provides for a more reliable packet loss duplication can hide a packet loss. However, when populating the ECN
indication. Reordering may also result in that packet loss is Feedback report, a receiver needs to track the sequence numbers
reported in one report and then removed in the next. 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 CE counter is actually more robust for packet duplication. The CE counter is robust for packet duplication. Adding each
Adding each received CE marked packet to the counter is not an issue. received CE marked packet to the counter is not an issue, in fact it
If one of the clones was CE marked that is still a indication of is required to ensure complete tracking of the ECN state. If one of
congestion. Packet duplication has potential impact on the ECN the clones was CE marked that is still an indication of congestion.
verification. Thus the sum of packets reported may be higher than Packet duplication has potential impact on the ECN verification and
the number sent. However, most detections are still applicable. thus there is a need to count the duplicates.
5.2. RTCP XR Report block for ECN summary information 5.2. RTCP XR Report block for ECN summary information
This unilateral XR report block combined with RTCP SR or RR report This unilateral XR report block combined with RTCP SR or RR report
blocks carries the same information as the ECN Feedback Packet and blocks carries the same information as the ECN Feedback Report and is
shall be based on the same underlying information. However, there is be based on the same underlying information. However, the ECN
a difference in semantics between the feedback format and this XR Feedback Report is intended to report on a CE mark as soon as
version. Where the feedback format is intended to report on a CE possible, while this extended report is for the regular RTCP
mark as soon as possible, this extended report is for the regular reporting and continuous verification of the ECN functionality end-
RTCP report and continuous verification of the ECN functionality end-
to-end. to-end.
The ECN Summary report block consists of one report block header: 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
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 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 | Reserved | Block Length | | BT=[TBA2] | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and then followed of one or more of the following report data blocks: Figure 3: RTCP XR Report Header
0 1 2 3 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 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 | | SSRC of Media Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Counter | not-ECT Counter | | CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter | ECT (1) Counter | | Loss Packet Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RTCP XR ECN Summary Report
The RTCP XR ECN Summary Report contains the following fields:
BT: Block Type identifying the ECN summary report block. Value is BT: Block Type identifying the ECN summary report block. Value is
[TBA2]. [TBA2].
Reserved: All bits SHALL be set to 0 on transmission and ignored on Reserved: All bits SHALL be set to 0 on transmission and ignored on
reception. reception.
Block Length: The length of the report block. Used to indicate the Block Length: The length of the report block. Used to indicate the
number of report data blocks present in the ECN summary report. number of report data blocks present in the ECN summary report.
This length will be 3*n, where n is the number of ECN summary This length will be 5*n, where n is the number of ECN summary
report blocks, since blocks are a fixed size. 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 octets,
since these cannot be valid.
SSRC of Media Sender: The SSRC identifying the media sender this SSRC of Media Sender: The SSRC identifying the media sender this
report is for. report is for.
CE Counter: as in Section 5.1.
ECT(0) Counter: as in Section 5.1. ECT(0) Counter: as in Section 5.1.
ECT(1) Counter: as in Section 5.1. ECT(1) Counter: as in Section 5.1.
CE Counter: as in Section 5.1.
not-ECT Counter: as in Section 5.1. not-ECT Counter: as in Section 5.1.
The Extended Highest Sequence number and the packet loss counter for Loss Packet Counter: as in Section 5.1.
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 information
available in SR or RR are the Extended Highest Sequence number and
the accumulated number of packet losses.
All the SSRCs that are present in the SR or RR SHALL also be included Duplication Counter: as in Section 5.1.
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 The Extended Highest Sequence number counter for each SSRC is not
summary for all the senders exceed the MTU, then only a subset of the present in RTCP XR report, in contrast to the feedback version. The
senders SHOULD be included so that the reports for the subset fits reason is that this summary report will rely on the information sent
within the MTU. The subsets SHOULD be selected round-robin across in the Sender Report (SR) or Receiver Report (RR) blocks part of the
multiple intervals so that all sources are reported. 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.
6. SDP Signalling Extensions for ECN 6. SDP Signalling Extensions for ECN
This section defines a number of SDP signalling extensions used in This section defines a number of SDP signalling extensions used in
the negotiation of the ECN for RTP support when using SDP. This the negotiation of the ECN for RTP support when using SDP. This
include one SDP attribute "ecn-capable-rtp" that negotiates the includes one SDP attribute "ecn-capable-rtp" that negotiates the
actual operation of ECN for RTP. Two SDP signalling parameters are actual operation of ECN for RTP. Two SDP signalling parameters are
defined to indicate the usage of the RTCP XR ECN summary block and defined to indicate the use of the RTCP XR ECN summary block and the
the AVPF feedback format for ECN. One ICE option SDP reprensenation RTP/AVPF feedback format for ECN. One ICE option SDP representation
is also defined. is also defined.
6.1. Signalling ECN Capability using SDP 6.1. Signalling ECN Capability using SDP
One new SDP attribute, "a=ecn-capable-rtp", is defined. This is a One new SDP attribute, "a=ecn-capable-rtp", is defined. This is a
media level attribute, thus it is normally included as part of the media level attribute, and MUST NOT be used at the session level. It
media description, but if present at session level the same is not subject to the character set chosen. The aim of this
configuration applies to all media descriptions. It is not subject signalling is to indicate the capability of the sender and receivers
to the character set chosen. The aim of this signalling is to support of ECN, and to negotiate the method of ECN initiation to be
indicate the capability of the sender and receivers to support ECN, used in the session. The attribute takes a list of initiation
and to negotiate the method of ECN initiation to be used in the methods, ordered in decreasing preference. The defined values for
session. The attribute takes a list of initiation methods, ordered the initiation method are:
in decreasing preference. The defined values for the initiation
method are:
rtp: Using RTP and RTCP as defined in Section 7.2.1. rtp: Using RTP and RTCP as defined in Section 7.2.1.
ice: Using STUN within ICE as defined in Section 7.2.2. 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. leap: Using the leap of faith method as defined in Section 7.2.3.
Further methods may be specified in the future, so unknown methods Further methods may be specified in the future, so unknown methods
MUST be ignored upon reception. MUST be ignored upon reception.
skipping to change at page 21, line 32 skipping to change at page 21, line 32
an outgoing UDP packet but not read them, while others may allow an outgoing UDP packet but not read them, while others may allow
applications to read the ECN bits but not set them. This applications to read the ECN bits but not set them. This
either/or case may produce an asymmetric support for ECN and thus either/or case may produce an asymmetric support for ECN and thus
should be conveyed in the SDP signalling. The "mode=setread" should be conveyed in the SDP signalling. The "mode=setread"
state is the ideal condition where an endpoint can both set and state is the ideal condition where an endpoint can both set and
read ECN bits in UDP packets. The "mode=setonly" state indicates read ECN bits in UDP packets. The "mode=setonly" state indicates
that an endpoint can set the ECT bit, but cannot read the ECN bits that an endpoint can set the ECT bit, but cannot read the ECN bits
from received UDP packets to determine if upstream congestion from received UDP packets to determine if upstream congestion
occurred. The "mode=readonly" state indicates that the endpoint occurred. The "mode=readonly" state indicates that the endpoint
can read the ECN bits to determine if congestion has occurred for can read the ECN bits to determine if congestion has occurred for
incomming packet, but it cannot set the ECT bits in outgoing UDP incoming packets, but it cannot set the ECT bits in outgoing UDP
packets. When the "mode=" parameter is omitted it is assumed that packets. When the "mode=" parameter is omitted it is assumed that
the node has "setread" capabilities. This option can provide for the node has "setread" capabilities. This option can provide for
an early indication that ECN cannot be used in a session. This an early indication that ECN cannot be used in a session. This
would be case when both the offerer and answerer set the "mode=" would be case when both the offerer and answerer set the "mode="
parameter to "setonly" or "readonly", or when an RTP sender entity parameter to "setonly" or "readonly".
considers offering "readonly".
ect: This parameter makes it possible to express the preferred ECT ect: This parameter makes it possible to express the preferred ECT
marking. This is either "random", "0", or "1", with "0" being marking. This is either "random", "0", or "1", with "0" being
implied if not specified. The "ect" parameter describes a implied if not specified. The "ect" parameter describes a
receiver preference, and is useful in the case where the receiver receiver preference, and is useful in the case where the receiver
knows it is behind a link using IP header compression, the knows it is behind a link using IP header compression, the
efficiency of which would be seriously disrupted if it were to efficiency of which would be seriously disrupted if it were to
receive packets with randomly chosen ECT marks. It is RECOMMENDED receive packets with randomly chosen ECT marks. It is RECOMMENDED
that ECT(0) marking be used. that ECT(0) marking be used.
The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp" attribute is The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp" attribute is
as follows: shown in Figure 5.
ecn-attribute = "a=ecn-capable-rtp:" SP init-list [SP parm-list] ecn-attribute = "a=ecn-capable-rtp:" SP init-list [SP parm-list]
init-list = init-value *("," init-value) init-list = init-value *("," init-value)
init-value = "rtp" / "ice" / "leap" / init-ext init-value = "rtp" / "ice" / "leap" / init-ext
init-ext = token init-ext = token
parm-list = parm-value *(";" SP parm-value) parm-list = parm-value *(";" SP parm-value)
parm-value = mode / ect / parm-ext parm-value = mode / ect / parm-ext
mode = "mode=" ("setonly" / "setread" / "readonly") mode = "mode=" ("setonly" / "setread" / "readonly")
ect = "ect=" ("0" / "1" / "random") ect = "ect=" ("0" / "1" / "random")
parm-ext = parm-name "=" parm-value-ext parm-ext = parm-name "=" parm-value-ext
parm-name = token parm-name = token
parm-value-ext = token / quoted-string parm-value-ext = token / quoted-string
quoted-string = DQUOTE *qdtext DQUOTE quoted-string = DQUOTE *qdtext DQUOTE
qdtext = %x20-21 / %x23-7E / %x80-FF qdtext = %x20-21 / %x23-7E / %x80-FF
; any 8-bit ascii except <"> ; any 8-bit ascii except <">
; external references: ; external references:
; token: from RFC 4566 ; token: from RFC 4566
; SP and DQUOTE from RFC 5234 ; SP and DQUOTE from RFC 5234
Figure 5: ABNF Grammar for the "a=ecn-capable-rtp" attribute
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 When SDP is used with the offer/answer model [RFC3264], the party
generating the SDP offer MUST insert an "a=ecn-capable-rtp" attribute generating the SDP offer MUST insert an "a=ecn-capable-rtp" attribute
into the media section of the SDP offer of each RTP flow for which it into the media section of the SDP offer of each RTP session for which
wishes to use ECN. The attribute includes one or more ECN initiation it wishes to use ECN. The attribute includes one or more ECN
methods in a comma separated list in decreasing order of preference, initiation methods in a comma separated list in decreasing order of
with any number of optional parameters following. The answering preference, with any number of optional parameters following. The
party compares the list of initiation methods in the offer with those answering party compares the list of initiation methods in the offer
it supports in order of preference. If there is a match, and if the with those it supports in order of preference. If there is a match,
receiver wishes to attempt to use ECN in the session, it includes an and if the receiver wishes to attempt to use ECN in the session, it
"a=ecn-capable-rtp" attribute containing its single preferred choice includes an "a=ecn-capable-rtp" attribute containing its single
of initiation method in the media sections of the answer. If there preferred choice of initiation method, and any optional parameters,
is no matching initiation method capability, or if the receiver does in the media sections of the answer. If there is no matching
not wish to attempt to use ECN in the session, it does not include an initiation method capability, or if the receiver does not wish to
"a=ecn-capable-rtp" attribute in its answer. If the attribute is attempt to use ECN in the session, it does not include an "a=ecn-
removed in the answer then ECN MUST NOT be used in any direction for capable-rtp" attribute in its answer. If the attribute is removed in
that media flow. If there are initilization methods that are the answer then ECN MUST NOT be used in any direction for that media
unknown, they MUST be ignored on reception and MUST NOT be included flow. If there are initialization methods that are unknown, they
in an answer. The answer may also include optional parameters, as MUST be ignored on reception and MUST NOT be included in an answer.
discussed below.
If the "mode=setonly" parameter is present in the "a=ecn-capable-rtp" The endpoints' capability to set and read ECN marks, as expressed by
attribute of the offer and the answering party is also the optional "mode=" parameter, determines whether ECN support can be
"mode=setonly", then there is no common ECN capability, and the negotiated for flows in one or both directions:
answer MUST NOT include the "a=ecn-capable-rtp" attribute.
Otherwise, if the offer is "mode=setonly" then ECN may only be
initiated in the direction from the offering party to the answering
party.
If the "mode=readonly" parameter is present in the "a=ecn-capable- o If the "mode=setonly" parameter is present in the "a=ecn-capable-
rtp" attribute of the offer and the answering party is rtp" attribute of the offer and the answering party is also
"mode=readonly", then there is no common ECN capability, and the "mode=setonly", then there is no common ECN capability, and the
answer MUST NOT include the "a=ecn-capable-rtp" attribute. answer MUST NOT include the "a=ecn-capable-rtp" attribute.
Otherwise, if the offer is "mode=readonly" then ECN may only be Otherwise, if the offer is "mode=setonly" then ECN may only be
initiated in the direction from the answering party to the offering initiated in the direction from the offering party to the
party. answering party.
If the "mode=setread" parameter is present in the "a=ecn-capable-rtp" o If the "mode=readonly" parameter is present in the "a=ecn-capable-
attribute of the offer and the answering party is "setonly", then ECN rtp" attribute of the offer and the answering party is
may only be initiated in the direction from the answering party to "mode=readonly", then there is no common ECN capability, and the
the offering party. If the offering party is "mode=setread" but the answer MUST NOT include the "a=ecn-capable-rtp" attribute.
answering party is "mode=readonly", then ECN may only be initiated in Otherwise, if the offer is "mode=readonly" then ECN may only be
the direction from the offering party to the answering party. If initiated in the direction from the answering party to the
both offer and answer are "mode=setread", then ECN may be initiated offering party.
in both directions. Note that "mode=setread" is implied by the
absence of a "mode=" parameter in the offer or the answer.
In an RTP session using multicast all participants intending to send o If the "mode=setread" parameter is present in the "a=ecn-capable-
RTP packets needs support setting ECT in the RTP packets, and all rtp" attribute of the offer and the answering party is "setonly",
participants receiving needs to have the capability to read ECN then ECN may only be initiated in the direction from the answering
values on incoming packets. Especially the later is important, party to the offering party. If the offering party is
otherwise no sender in the multicast session will be able to enable "mode=setread" but the answering party is "mode=readonly", then
ECN. If a session is negotiated using offer/answer it is preferable ECN may only be initiated in the direction from the offering party
that intended session participant would be aware of the signalling to the answering party. If both offer and answer are
attributes and if not capable but ECN for RTP aware SHOULD refuse to "mode=setread", then ECN may be initiated in both directions.
join the session. For intended session participants that are not Note that "mode=setread" is implied by the absence of a "mode="
aware of the ECN for RTP signalling and simple ignore the signalling parameter in the offer or the answer.
attribute the other party in the offer/answer exchange SHOULD
terminate the SIP dialog so that the participant leaves the session. o An offer that does not include a "mode=" parameter MUST be treated
as-if a "mode=setread" parameter had been included.
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 The "ect=" parameter in the "a=ecn-capable-rtp" attribute is set
independently in the offer and the answer. Its value in the offer independently in the offer and the answer. Its value in the offer
indicates a preference for the sending behaviour of the answering indicates a preference for the sending behaviour of the answering
party, and its value in the answer indicates a sending preference for party, and its value in the answer indicates a sending preference for
the behaviour of the offering party. It will be the senders choice the behaviour of the offering party. It will be the senders choice
to honour the receivers preference for what to receive or not. In to honour the receivers preference for what to receive or not. In
multicast sessions, any sender SHOULD send using the value declared multicast sessions, all senders SHOULD set the ECT marks using the
in the ect parameter. value declared in the "ect=" parameter.
Unknown optional parameters MUST be ignored on reception, and MUST Unknown optional parameters MUST be ignored on reception, and MUST
NOT be included in the answer. That way new parameters may be NOT be included in the answer. That way new parameters may be
introduced and verified to be supported by the other end-point by introduced and verified to be supported by the other end-point by
having them include it in any answer. having them include it in any answer.
6.1.2. Use of "a=ecn-capable-rtp:" with Declarative SDP
When SDP is used in a declarative manner, for example in a multicast When SDP is used in a declarative manner, for example in a multicast
session using the Session Announcement Protocol (SAP, [RFC2974]), session using the Session Announcement Protocol (SAP, [RFC2974]),
negotiation of session description parameters is not possible. The negotiation of session description parameters is not possible. The
"a=ecn-capable-rtp" attribute MAY be added to the session description "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 to indicate that the sender will use ECN in the RTP session. The
attribute MUST include a single method of initiation. Participants attribute MUST include a single method of initiation. Participants
MUST NOT join such a session unless they have the capability to MUST NOT join such a session unless they have the capability to
receive ECN-marked UDP packets, implement the method of initiation, receive ECN-marked UDP packets, implement the method of initiation,
and can generate RTCP ECN feedback (note that having the capability and can generate RTCP ECN feedback. The mode parameter MAY also be
to use ECN doesn't necessarily imply that the underlying network path included in declarative usage, to indicate the minimal capability is
between sender and receiver supports ECN). The mode parameter MAY be required by the consumer of the SDP. So for example in a SSM session
included also in declarative usage, to indicate the minimal the participants configured with a particular SDP will all be in a
capability is required by the consumer of the SDP. So for example in media receive only mode, thus mode=readonly will work as the
a SSM session the participants configured with a particular SDP will capability of reporting on the ECN markings in the received is what
all be in a media receive only mode, thus mode=readonly will work as is required. However, using "mode=readonly" also in ASM sessions is
the capability of reporting on the ECN markings in the received is reasonable, unless all senders are required to attempt to use ECN for
what is required. However, using "mode=readonly" also in ASM their outgoing RTP data traffic, in which case the mode needs to be
sessions is reasonable, unless all senders are required to attempt to set to "setread".
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 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 using UDP/IP transport. It MUST NOT be used for RTP sessions using
TCP, SCTP, or DCCP transport, or for non-RTP sessions. TCP, SCTP, or DCCP transport, or for non-RTP sessions.
As described in Section 7.3.3, RTP sessions using ECN require rapid 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 RTCP ECN feedback, unless timely feedback is not required due to a
receiver driven congestion control. To ensure that the sender can receiver driven congestion control. To ensure that the sender can
react to ECN-CE marked packets timely feedback is usually required. react to ECN-CE marked packets timely feedback is usually required.
Thus, the use of the Extended RTP Profile for RTCP-Based Feedback Thus, the use of the Extended RTP Profile for RTCP-Based Feedback
(RTP/AVPF) [RFC4585] or other profile that inherits AVPF's signalling (RTP/AVPF) [RFC4585] or other profile that inherits RTP/AVPF's
rules, MUST be signalled unless timely feedback is not required. If signalling rules, MUST be signalled unless timely feedback is not
timely feedback is not required it is still RECOMMENDED to used AVPF. required. If timely feedback is not required it is still RECOMMENDED
The signalling of an AVPF based profile is likely to be required even to used RTP/AVPF. The signalling of an RTP/AVPF based profile is
if the preferred method of initialization and the congestion control likely to be required even if the preferred method of initialization
does not require timely feedback, as the common interoperable method and the congestion control does not require timely feedback, as the
is likely to be signalled or the improved fault reaction is desired. common interoperable method is likely to be signalled or the improved
fault reaction is desired.
6.2. RTCP Feedback SDP Parameter 6.2. RTCP ECN Feedback SDP Parameter
A new "nack" feedback parameter "ecn" is defined to indicate the A new "nack" feedback parameter "ecn" is defined to indicate the
usage of the RTCP ECN feedback packet format (Section 5.1). The ABNF usage of the RTCP ECN feedback packet format (Section 5.1). The ABNF
[RFC5234] definition of the SDP parameter extension is: [RFC5234] definition of the SDP parameter extension is:
rtcp-fb-nack-param = <See section 4.2 of RFC 4585> rtcp-fb-nack-param = <See section 4.2 of RFC 4585>
rtcp-fb-nack-param /= ecn-fb-par rtcp-fb-nack-param /= ecn-fb-par
ecn-fb-par = SP "ecn" ecn-fb-par = SP "ecn"
The offer/answer rules for this SDP feedback parameters are specified The offer/answer rules for this SDP feedback parameters are specified
in AVPF [RFC4585]. in the RTP/AVPF profile [RFC4585].
6.3. XR Block SDP Parameter 6.3. XR Block ECN SDP Parameter
A new unilateral RTCP XR block for ECN summary information is A new unilateral RTCP XR block for ECN summary information is
specified, thus the XR block SDP signalling also needs to be extended 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 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 blocks. The XR block SDP attribute as defined in Section 5.1 of the
RTCP XR specification [RFC3611] is defined to be extendible. As no RTCP XR specification [RFC3611] is defined to be extendible. As no
parameter values are needed for this ECN summary block, this parameter values are needed for this ECN summary block, this
parameter extension consistis of a simple parameter name used to parameter extension consists of a simple parameter name used to
indicate support and intent to use the XR block. indicate support and intent to use the XR block.
xr-format = <See Section 5.1 of [RFC3611]> xr-format = <See Section 5.1 of [RFC3611]>
xr-format /= ecn-summary-par xr-format /= ecn-summary-par
ecn-summary-par = "ecn-sum" ecn-summary-par = "ecn-sum"
For SDP declarative and offer/answer usage, see the RTCP XR For SDP declarative and offer/answer usage, see the RTCP XR
specification[RFC3611] and its specifciation of how to handle specification [RFC3611] and its description of how to handle
unilateral parameters. unilateral parameters.
6.4. ICE Parameter to Signal ECN Capability 6.4. ICE Parameter to Signal ECN Capability
One new ICE [RFC5245] option, "rtp+ecn", is defined. This is used 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 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 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"). 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 The answering party includes this same attribute at the session level
in the SDP answer if it also has the capability, and removes the in the SDP answer if it also has the capability, and removes the
skipping to change at page 26, line 8 skipping to change at page 26, line 20
7. Use of ECN with RTP/UDP/IP 7. Use of ECN with RTP/UDP/IP
In the detailed specification of the behaviour below, the different In the detailed specification of the behaviour below, the different
functions in the general case will first be discussed. In case functions in the general case will first be discussed. In case
special considerations are needed for middleboxes, multicast usage special considerations are needed for middleboxes, multicast usage
etc, those will be specially discussed in related subsections. etc, those will be specially discussed in related subsections.
7.1. Negotiation of ECN Capability 7.1. Negotiation of ECN Capability
The first stage of ECN negotiation for RTP-over-UDP is to signal the The first stage of ECN negotiation for RTP-over-UDP is to signal the
capability to use ECN. This includes negotiating if ECN is to be capability to use ECN. An RTP system that supports ECN and uses SDP
used symmetrically and the method for initial ECT verification. This for its signalling MUST implement the SDP extension to signal ECN
memo defines the mappings of this information onto SDP for both capability as described in Section 6.1, the RTCP ECN feedback SDP
declarative and offer/answer usage. There is one SDP extension to parameter defined in Section 6.2, and the XR Block ECN SDP parameter
indicate if ECN support should be used, and the method for initiation defined in Section 6.3. It MAY also implement alternative ECN
(Section 6.1). Further parameters to indicate support for the AVPF
ECN feedback format (Section 6.2) and the ECN XR summary report
(Section 6.3). In addition an ICE parameter is defined (Section 6.4)
to indicate that ECN initiation using STUN is supported as part of an
ICE exchange.
An RTP system that supports ECN and uses SDP in the signalling MUST
implement the SDP extension to signal ECN capability as described in
Section 6.1, the ECN feedback SDP parameter Section 6.2, and the ECN
XR SDP parameter Section 6.3. It MAY also implement alternative ECN
capability negotiation schemes, such as the ICE extension described capability negotiation schemes, such as the ICE extension described
in Section 6.4. in Section 6.4. Other signalling systems needs to define the
corresponding signalling parameters to what is defined for SDP.
The "ecn-capable-rtp" SDP attribute MUST always be used when The "ecn-capable-rtp" SDP attribute MUST always be used when
employing ECN for RTP according to this specification. As the XR ECN employing ECN for RTP according to this specification in systems
summary report is required independently of the initialization using SDP. As the RTCP XR ECN summary report is required
method, or congestion control scheme the "rtcp-xr" attribute with the independently of the initialization method or congestion control
"ecn-sum" parameter MUST also be used. The "rtcp-fb" attribute with scheme, the "rtcp-xr" attribute with the "ecn-sum" parameter MUST
the "nack" parameter "ecn" MUST be used whenever the initialization also be used. The "rtcp-fb" attribute with the "nack" parameter
method or a congestion control algorithm requiring timely sender side "ecn" MUST be used whenever the initialization method or a congestion
knowledge of received CE markings. If the congestion control scheme control algorithm requiring timely sender side knowledge of received
uses additional signalling they should be indicated as appropriate CE markings. If the congestion control scheme uses additional
for those signalling methods. signalling they should be indicated as appropriate for those
signalling methods.
7.2. Initiation of ECN Use in an RTP Session 7.2. Initiation of ECN Use in an RTP Session
Once the sender and the receiver(s) have agreed that they have the 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 capability to use ECN within a session, they may attempt to initiate
ECN use. ECN use. All session participants connected over the same transport
will need to 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 and ensure to be consistent with the ECN support in
those cases the mixer or translator 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 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 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 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 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 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 the sender and the receivers exhibits either of these behaviours one
needs to stop using ECN immediately to protect both the network and needs to stop using ECN immediately to protect both the network and
the application. the application.
The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic 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 at any time. This is to ensure that packet loss due to ECN marking
will not effect the RTCP traffic and the necessary feedback will not effect the RTCP traffic and the necessary feedback
information it carries. information it carries.
An RTP system that supports ECN MUST implement the initiation of ECN 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 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 implement other mechanisms to initiate ECN support, for example the
STUN-based mechanism described in Section 7.2.2 or use the leap of STUN-based mechanism described in Section 7.2.2, or use the leap of
faith option if the session supports the limitations provided in faith option if the session supports the limitations provided in
Section 7.2.3. If support for both in-band and out-of-band Section 7.2.3. If support for both in-band and out-of-band
mechanisms is signalled, the sender should try ECN negotiation using mechanisms is signalled, the sender SHOULD try ECN negotiation using
STUN with ICE first, and if it fails, fallback to negotiation using STUN with ICE first, and if it fails, fallback to negotiation using
RTP and RTCP ECN feedback. RTP and RTCP ECN feedback.
No matter how ECN usage is initiated, the sender MUST continually No matter how ECN usage is initiated, the sender MUST continually
monitor the ability of the network, and all its receivers, to support monitor the ability of the network, and all its receivers, to support
ECN, following the mechanisms described in Section 7.4. This is ECN, following the mechanisms described in Section 7.4. This is
necessary because path changes or changes in the receiver population necessary because path changes or changes in the receiver population
may invalidate the ability of the system to use ECN. may invalidate the ability of the system to use ECN.
7.2.1. Detection of ECT using RTP and RTCP 7.2.1. Detection of ECT using RTP and RTCP
The ECN initiation phase using RTP and RTCP to detect if the network The ECN initiation phase using RTP and RTCP to detect if the network
path supports ECN comprises three stages. Firstly, the RTP sender path supports ECN comprises three stages. Firstly, the RTP sender
generates some small fraction of its traffic with ECT marks to act a 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, probe for ECN support. Then, on receipt of these ECT-marked packets,
the receivers send RTCP ECN feedback packets and RTCP ECN summary the receivers send RTCP ECN feedback packets and RTCP ECN summary
reports to inform the sender that their path supports ECN. Finally, 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 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. the paths to all RTP receivers have been verified to support ECN.
Generating ECN Probe Packets: During the ECN initiation phase, an Generating ECN Probe Packets: During the ECN initiation phase, an
RTP sender SHALL mark a small fraction of its RTP traffic as ECT, RTP sender SHALL mark a small fraction of its RTP traffic as ECT,
while leaving the reminder of the packets unmarked. The main while leaving the reminder of the packets unmarked. The main
reason for only marking some packets is to maintain usable media reason for only marking some packets is to maintain usable media
delivery during the ECN initiation phase in those cases where ECN delivery during the ECN initiation phase in those cases where ECN
is not supported by the network path. A secondary reason to send is not supported by the network path. A secondary reason to send
some not-ECT packets are to ensure that the receivers will send some not-ECT packets are to ensure that the receivers will send
RTCP reports on this sender, even if all ECT marked packets are RTCP reports on this sender, even if all ECT marked packets are
lost in transit. The not-ECT packets also provide a base-line to lost in transit. The not-ECT packets also provide a base-line to
compare performance parameters against. A fourth reason for only compare performance parameters against. A fourth reason for only
probing with a small number of packets is to reduce the risk that probing with a small number of packets is to reduce the risk that
significant numbers of congestion markings might be lost if ECT is significant numbers of congestion markings might be lost if ECT is
cleared to Not-ECT by an ECN-Reverting Meddlebox. Then any cleared to Not-ECT by an ECN-Reverting Middlebox. Then any
resulting lack of congestion response is likely to have little resulting lack of congestion response is likely to have little
damaging affect on others. An RTP sender is RECOMMENDED to send a damaging affect on others. An RTP sender is RECOMMENDED to send a
minimum of two packets with ECT markings per RTCP reporting minimum of two packets with ECT markings per RTCP reporting
interval. In case an random ECT pattern is intended to be used, interval. In case a random ECT pattern is intended to be used, at
at least one with ECT(0) and one with ECT(1) per reporting least one packet with ECT(0) and one with ECT(1) should be sent
interval, in case a single ECT marking is to be used, only that per reporting interval, in case a single ECT marking is to be
ECT value SHOULD be sent. The RTP sender will continue to send used, only that ECT value SHOULD be sent. The RTP sender SHALL
some ECT marked traffic as long as the ECN initiation phase continue to send some ECT marked traffic as long as the ECN
continues. The sender SHOULD NOT mark all RTP packets as ECT initiation phase continues. The sender SHOULD NOT mark all RTP
during the ECN initiation phase. packets as ECT during the ECN initiation phase.
This memo does not mandate which RTP packets are marked with ECT This memo does not mandate which RTP packets are marked with ECT
during the ECN initiation phase. An implementation should insert during the ECN initiation phase. An implementation should insert
ECT marks in RTP packets in a way that minimises the impact on ECT marks in RTP packets in a way that minimises the impact on
media quality if those packets are lost. The choice of packets to media quality if those packets are lost. The choice of packets to
mark is clearly very media dependent, but the usage of RTP NO-OP mark is clearly very media dependent, but the use of RTP NO-OP
payloads [I-D.ietf-avt-rtp-no-op], if supported, would be an payloads [I-D.ietf-avt-rtp-no-op], if supported, would be an
appropriate choice. For audio formats, if would make sense for appropriate choice. For audio formats, if would make sense for
the sender to mark comfort noise packets or similar. For video the sender to mark comfort noise packets or similar. For video
formats, packets containing P- or B-frames, rather than I-frames, formats, packets containing P- or B-frames, rather than I-frames,
would be an appropriate choice. No matter which RTP packets are would be an appropriate choice. No matter which RTP packets are
marked, those packets MUST NOT be sent in duplicate with and marked, those packets MUST NOT be sent in duplicate with and
without ECT, since their RTP sequence number is used to identify without ECT, since their RTP sequence number is used to identify
packets that are received with ECN markings. packets that are received with ECN markings.
Generating RTCP ECN Feedback: If ECN capability has been negotiated Generating RTCP ECN Feedback: If ECN capability has been negotiated
skipping to change at page 29, line 4 skipping to change at page 29, line 20
membership changes after the ECN initiation phase has completed membership changes after the ECN initiation phase has completed
are discussed in Section 7.3). are discussed in Section 7.3).
An RTP sender shall consider the group membership to be stable An RTP sender shall consider the group membership to be stable
after it has been in the session and sending ECT-marked probe after it has been in the session and sending ECT-marked probe
packets for at least three RTCP reporting intervals (i.e., after packets for at least three RTCP reporting intervals (i.e., after
sending its third regularly scheduled RTCP packet), and when a sending its third regularly scheduled RTCP packet), and when a
complete RTCP reporting interval has passed without changes to the complete RTCP reporting interval has passed without changes to the
group membership. ECN initiation is considered successful when group membership. ECN initiation is considered successful when
the group membership is stable, and all known participants have the group membership is stable, and all known participants have
sent one or more RTCP ECN feedback packets indicating correct sent one or more RTCP ECN feedback packets or RTCP XR ECN summary
receipt of the ECT-marked RTP packets generated by the sender. 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 As an optimisation, if an RTP sender is initiating ECN usage
towards a unicast address, then it MAY treat the ECN initiation as towards a unicast address, then it MAY treat the ECN initiation as
provisionally successful if it receives a single RTCP ECN feedback provisionally successful if it receives an RTCP ECN feedback
report indicating successful receipt of the ECT-marked packets, report or an RTCP XR ECN summary report indicating successful
with no negative indications, from a single RTP receiver. After receipt of the ECT-marked packets, with no negative indications,
from a single RTP receiver (where 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 declaring provisional success, the sender MAY generate ECT-marked
packets as described in Section 7.3, provided it continues to packets as described in Section 7.3, provided it continues to
monitor the RTCP reports for a period of three RTCP reporting monitor the RTCP reports for a period of three RTCP reporting
intervals from the time the ECN initiation started, to check if intervals from the time the ECN initiation started, to check if
there is any other participants in the session. If other there are any other participants in the session. Thus as long as
participants are detected, the sender MUST fallback to only ECT- any additional SSRC that report on the ECN usage are using the
marking a small fraction of its RTP packets, while it determines same CNAME as the previous reports and they are all indicating
if ECN can be supported following the full procedure described functional ECN the sender may continue. If other participants are
above. detected, i.e., other CNAMEs, the sender MUST fallback to only
ECT-marking a small fraction of its RTP packets, while it
determines if ECN can be supported following the full procedure
described above. Different CNAMEs received over an unicast
transport may occur when using translators in a multi-party RTP
session (e.g., when using a centralised conference bridge).
Note: One use case that requires further consideration is a Note: The above optimization supports peer to peer unicast
unicast connection with several SSRCs multiplexed onto the same transport with several SSRCs multiplexed onto the same flow
flow (e.g., an SVC video using SSRC multiplexing for the (e.g., SSRC multiplexed RTP retransmission [RFC4588]). It is
layers). It is desirable to be able to rapidly negotiate ECN desirable to be able to rapidly negotiate ECN support for such
support for such a session, but the optimisation above fails a session, but the optimisation above can fail if there are
since the multiple SSRCs make it appear that this is a group implementations that use the same CNAME for different parts of
communication scenario. It's not sufficient to check that all a distributed implementation that have different transport
SSRCs map to a common RTCP CNAME to check if they're actually characteristics (e.g., if a single logical endpoint is split
located on the same device, because there are implementations across multiple hosts).
that use the same CNAME for different parts of a distributed
implementation.
ECN initiation is considered to have failed at the instant when ECN initiation is considered to have failed at the instant when
any RTP session participant sends an RTCP packet that doesn't any RTP session participant sends an RTCP packet that doesn't
contain an RTCP ECN feedback report or ECN summary report, but has contain an RTCP ECN feedback report or ECN summary report, but has
an RTCP RR with an extended RTP sequence number field that an RTCP RR with an extended RTP sequence number field that
indicates that it should have received multiple (>3) ECT marked indicates that it should have received multiple (>3) ECT marked
RTP packets. This can be due to failure to support the ECN RTP packets. This can be due to failure to support the ECN
feedback format by the receiver or some middlebox, or the loss of feedback format by the receiver or some middlebox, or the loss of
all ECT marked packets. Both indicate a lack of ECN support. all ECT marked packets. Both indicate a lack of ECN support.
skipping to change at page 30, line 17 skipping to change at page 30, line 38
7.2.2. Detection of ECT using STUN with ICE 7.2.2. Detection of ECT using STUN with ICE
This section describes an OPTIONAL method that can be used to avoid This section describes an OPTIONAL method that can be used to avoid
media impact and also ensure an ECN capable path prior to media media impact and also ensure an ECN capable path prior to media
transmission. This method is considered in the context where the transmission. This method is considered in the context where the
session participants are using ICE [RFC5245] to find working session participants are using ICE [RFC5245] to find working
connectivity. We need to use ICE rather than STUN only, as the connectivity. We need to use ICE rather than STUN only, as the
verification needs to happen from the media sender to the address and verification needs to happen from the media sender to the address and
port on which the receiver is listening. 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 needs to
either not allow this method (use the RTP/RTCP method instead) or
implement additional handling for this case 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 To minimise the impact of set-up delay, and to prioritise the fact
that one has a working connectivity rather than necessarily finding that one has a working connectivity rather than necessarily finding
the best ECN capable network path, this procedure is applied after the best ECN capable network path, this procedure is applied after
having performed a successful connectivity check for a candidate, having performed a successful connectivity check for a candidate,
which is nominated for usage. At that point, and provided the chosen which is nominated for usage. At that point an additional
candidate is not a relayed address, an additional connectivity check connectivity check is performed, sending the "ECN Check" attribute in
is performed, sending the "ECT Check" attribute in a STUN packet that a STUN packet that is ECT marked. On reception of the packet, a STUN
is ECT marked. On reception of the packet, a STUN server supporting server supporting this extension will note the received ECN field
this extension will note the received ECN field value, and send a value, and send a STUN/UDP/IP packet in reply with the ECN field set
STUN/UDP/IP packet in reply, with the ECN field set to not-ECT, and to not-ECT and including an ECN check attribute. A STUN server that
including an ECN check attribute. A STUN server that doesn't doesn't understand the extension, or is incapable of reading the ECN
understand the extension or is incapable of reading the ECN values on values on incoming STUN packets, should follow the rule in the STUN
incoming STUN packets should follow the STUN specifications rule for specification for unknown comprehension-optional attributes, and
unknown comprehension-optional attributes, i.e. ignore the attribute. ignore the attribute, resulting in the sender receiving a STUN
Which will result in the sender receiving a STUN response but without response without the ECN Check STUN attribute.
the ECN Check STUN attribute.
The STUN ECN check attribute contains one field and a flag. The flag The STUN ECN check attribute contains one field and a flag, as shown
indicates whether the echo field contains a valid value or not. The in Figure 6. The flag indicates whether the echo field contains a
field is the ECN echo field, and when valid contains the two ECN bits valid value or not. The field is the ECN echo field, and when valid
from the packet it echoes back. The ECN check attribute is a contains the two ECN bits from the packet it echoes back. The ECN
comprehension optional attribute. check attribute is a comprehension optional attribute.
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |ECF|V| | Reserved |ECF|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ECN Check STUN Attribute Figure 6: ECN Check STUN Attribute
V: Valid (1 bit) ECN Echo value field is valid when set to 1, and V: Valid (1 bit) ECN Echo value field is valid when set to 1, and
invalid when set 0. invalid when set 0.
ECF: ECN Echo value field (2 bits) contains the ECN field value of ECF: ECN Echo value field (2 bits) contains the ECN field value of
the STUN packet it echoes back when field is valid. If invalid the STUN packet it echoes back when field is valid. If invalid
the content is arbitrary. the content is arbitrary.
Reserved: Reserved bits (29 bits) SHALL be set to 0 on transmission, Reserved: Reserved bits (29 bits) SHALL be set to 0 on transmission,
and SHALL be ignored on reception. and SHALL be ignored on reception.
skipping to change at page 31, line 26 skipping to change at page 32, line 7
field to be echoed back. In STUN requests the V bit SHALL be set to 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 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 attribute SHALL read the ECN field value of the IP/UDP packet the
request was received in. Upon forming the response the server SHALL 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 ECN Check attribute setting the V bit to valid and
include the read value of the ECN field into the ECF field. If the 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 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 ECN value of the STUN request, it SHALL set the V bit in the response
to 0. The STUN client may retry immediately. 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 fragments or reassembles
packets as they do not separate the ECN control loops between the
end-points and the translator. Such a translator that uses ICE based
initialization needs to 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 or
correctly handles 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.
7.2.3. Leap of Faith ECT initiation method 7.2.3. Leap of Faith ECT initiation method
This method for initiating ECN usage is a leap of faith that assumes 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 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 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 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 to detect any case when the assumption that the path was ECT capable
is wrong. This method is only recommended for controlled is wrong. This method is only recommended for controlled
environments where the whole path(s) between sender and receiver(s) environments where the whole path(s) between sender and receiver(s)
has been built and verified to be ECT. has been built and verified to be ECT.
skipping to change at page 32, line 28 skipping to change at page 33, line 33
7.3.1. Transmission of ECT-marked RTP Packets 7.3.1. Transmission of ECT-marked RTP Packets
After a sender has successfully initiated ECN usage, it SHOULD mark After a sender has successfully initiated ECN usage, it SHOULD mark
all the RTP data packets it sends as ECT. The sender 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 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" ECT(1) or random using the "ect" parameter in the "a=ecn-capable-rtp"
attribute. attribute.
The sender SHALL NOT include ECT marks on outgoing RTCP packets, and The sender SHALL NOT include ECT marks on outgoing RTCP packets, and
SHOULD NOT include ECT marks on any other outgoing control messages SHOULD NOT include ECT marks on any other outgoing control messages
(e.g. STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or (e.g., STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or
ZRTP [I-D.zimmermann-avt-zrtp] control packets) that are multiplexed ZRTP [RFC6189] control packets) that are multiplexed on the same UDP
on the same UDP port. For control packets there might be exceptions, port. For control packets there might be exceptions, like the STUN
like the STUN based ECN check defined in Section 7.2.2. based ECN check defined in Section 7.2.2.
7.3.2. Reporting ECN Feedback via RTCP 7.3.2. Reporting ECN Feedback via RTCP
An RTP receiver that receives a packet with an ECN-CE mark, or that 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 detects a packet loss, MUST schedule the transmission of an RTCP ECN
feedback packet as soon as possible (subject to the constraints of feedback packet as soon as possible (subject to the constraints of
[RFC4585] and [RFC3550]) to report this back to the sender unless no [RFC4585] and [RFC3550]) to report this back to the sender unless no
timely feedback required. There should be no difference in behavior timely feedback required. There should be no difference in behavior
if ECN-CE marks or packet drops are detected. The feedback RTCP if ECN-CE marks or packet drops are detected. The feedback RTCP
packet sent SHALL consist of at least one ECN feedback packet packet sent SHALL consist of at least one ECN feedback packet
(Section 5) reporting on the packets received since the last ECN (Section 5.1) reporting on the packets received since the last ECN
feedback packet, and SHOULD contain an RTCP SR or RR packet. The feedback packet, and will contain an RTCP SR or RR packet unless
RTP/AVPF profile in early or immediate feedback mode SHOULD be used reduced size RTCP [RFC5506] is used. The RTP/AVPF profile in early
where possible, to reduce the interval before feedback can be sent. or immediate feedback mode SHOULD be used where possible, to reduce
To reduce the size of the feedback message, reduced size RTCP the interval before feedback can be sent. To reduce the size of the
[RFC5506] MAY be used if supported by the end-points. Both RTP/AVPF feedback message, reduced size RTCP [RFC5506] MAY be used if
and reduced size RTCP MUST be negotiated in the session set-up supported by the end-points. Both RTP/AVPF and reduced size RTCP
signalling before they can be used. 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 Every time a regular compound RTCP packet is to be transmitted, an
ECN-capable RTP receiver MUST include an RTCP XR ECN summary report ECN-capable RTP receiver MUST include an RTCP XR ECN summary report
as described in Section 5.2 as part of the compound packet. as described in Section 5.2 as part of the compound packet.
The multicast feedback implosion problem, that occurs when many The multicast feedback implosion problem, that occurs when many
receivers simultaneously send feedback to a single sender, must also receivers simultaneously send feedback to a single sender, must be
be considered. The RTP/AVPF transmission rules will limit the amount considered. The RTP/AVPF transmission rules will limit the amount of
of feedback that can be sent, avoiding the implosion problem but also feedback that can be sent, avoiding the implosion problem but also
delaying feedback by varying degrees from nothing up to a full RTCP delaying feedback by varying degrees from nothing up to a full RTCP
reporting interval. As a result, the full extent of a congestion reporting interval. As a result, the full extent of a congestion
situation may take some time to reach the sender, although some situation may take some time to reach the sender, although some
feedback should arrive in a reasonably timely manner, allowing the feedback should arrive in a reasonably timely manner, allowing the
sender to react on a single or a few reports. sender to react on a single or a few reports.
A possible future optimisation might be to define some form of
feedback suppression mechanism to reduce the RTCP reporting
overhead for group communication using ECN.
7.3.3. Response to Congestion Notifications 7.3.3. Response to Congestion Notifications
The reception of RTP packets with ECN-CE marks in the IP header are a The reception of RTP packets with ECN-CE marks in the IP header are a
notification that congestion is being experience. The default notification that congestion is being experienced. The default
reaction on the reception of these ECN-CE marked packets MUST be to reaction on the reception of these ECN-CE marked packets MUST be to
provide the congestion control algorithm with notification and that provide the congestion control algorithm with a congestion
it is treated as a packet loss would when it comes to indicating notification, that triggers the algorithm to react as if packet loss
congestion. had occurred.
We note that there MAY be other reactions to ECN-CE specified in the We note that there MAY be other reactions to ECN-CE specified in the
future. Such an alternative reaction MUST be specified and future. Such an alternative reaction MUST be specified and
considered to be safe for deployment under any restrictions considered to be safe for deployment under any restrictions
specified. A potential example for an alternative reaction could be specified. A potential example for an alternative reaction could be
emergency communications (such as that generated by first responders, emergency communications (such as that generated by first responders,
as opposed to the general public) in networks where the user has been as opposed to the general public) in networks where the user has been
authorized. A more detailed description of these other reactions, as authorized. A more detailed description of these other reactions, as
well as the types of congestion control algorithms used by end-nodes, well as the types of congestion control algorithms used by end-nodes,
is outside of the scope of this document. is outside of the scope of this document.
Depending on the media format, type of session, and RTP topology Depending on the media format, type of session, and RTP topology
used, there are several different types of congestion control that used, there are several different types of congestion control that
can be used. can be used:
Sender-Driven Congestion Control: The sender may be responsible for Sender-Driven Congestion Control: The sender is responsible for
adapting the transmitted bit-rate in response to RTCP ECN adapting the transmitted bit-rate in response to RTCP ECN
feedback. When the sender receives the ECN feedback data it feeds feedback. When the sender receives the ECN feedback data it feeds
this information into its congestion control or bit-rate this information into its congestion control or bit-rate
adaptation mechanism so that it can react on it as if it was adaptation mechanism so that it can react to it as if packet loss
packet losses that was reported. The congestion control algorithm was reported. The congestion control algorithm to be used is not
to be used is not specified here, although TFRC [RFC5348] is one specified here, although TFRC [RFC5348] is one example that might
example that might be used. be used.
Receiver-Driven Congestion Control: If a receiver driven congestion Receiver-Driven Congestion Control: If a receiver driven congestion
control mechanism is used, the receiver can react to the ECN-CE control mechanism is used, the receiver can react to the ECN-CE
marks without contacting the sender. This may allow faster marks without contacting the sender. This may allow faster
response than sender-driven congestion control in some response than sender-driven congestion control in some
circumstances. Receiver-driven congestion control is usually circumstances. Receiver-driven congestion control is usually
implemented by providing the content in a layered way, with each implemented by providing the content in a layered way, with each
layer providing improved media quality but also increased layer providing improved media quality but also increased
bandwidth usage. The receiver locally monitors the ECN-CE marks bandwidth usage. The receiver locally monitors the ECN-CE marks
on received packet to check if it experiences congestion at the on received packets to check if it experiences congestion with the
current number of layers. If congestion is experienced, the current number of layers. If congestion is experienced, the
receiver drops one layer, so reducing the resource consumption on receiver drops one layer, so reducing the resource consumption on
the path towards itself. For example, if a layered media encoding the path towards itself. For example, if a layered media encoding
scheme such as H.264 SVC is used, the receiver may change its scheme such as H.264 SVC is used, the receiver may change its
layer subscription, and so reduce the bit rate it receives. The layer subscription, and so reduce the bit rate it receives. The
receiver MUST still send RTCP XR ECN Summary to the sender, even receiver MUST still send RTCP XR ECN Summary to the sender, even
if it can adapt without contact with the sender, so that the if it can adapt without contact with the sender, so that the
sender can determine if ECN is supported on the network path. The sender can determine if ECN is supported on the network path. The
timeliness of RTCP feedback is less of a concern with receiver timeliness of RTCP feedback is less of a concern with receiver
driven congestion control, and regular RTCP reporting of ECN driven congestion control, and regular RTCP reporting of ECN
summary information is sufficient (without using RTP/AVPF summary information is sufficient (without using RTP/AVPF
immediate or early feedback). immediate or early feedback).
Hybrid: There might be mechanisms that utilize both some receiver Hybrid: There might be mechanisms that utilize both some receiver
behaviors and some sender side monitoring, thus requiring both behaviors and some sender side monitoring, thus requiring both
feedback of congestion events to the sender and taking receiver feedback of congestion events to the sender and taking receiver
decisions and possible signalling to the sender. From this decisions and possible signalling to the sender. In this case the
solution the congestion control algorithm needs to use the congestion control algorithm needs to use the signalling to
signalling to indicate which functions of ECN that is needed to be indicate which features of ECN for RTP are required.
used.
Responding to congestion indication in the case of multicast traffic Responding to congestion indication in the case of multicast traffic
is a more complex problem than for unicast traffic. The fundamental is a more complex problem than for unicast traffic. The fundamental
problem is diverse paths, i.e. when different receivers don't see the problem is diverse paths, i.e., when different receivers don't see
same path, and thus have different bottlenecks, so the receivers may the same path, and thus have different bottlenecks, so the receivers
get ECN-CE marked packets due to congestion at different points in may get ECN-CE marked packets due to congestion at different points
the network. This is problematic for sender driven congestion in the network. This is problematic for sender driven congestion
control, since when receivers are heterogeneous in regards to control, since when receivers are heterogeneous in regards to
capacity the sender is limited to transmitting at the rate the capacity the sender is limited to transmitting at the rate the
slowest receiver can support. This often becomes a significant slowest receiver can support. This often becomes a significant
limitation as group size grows. Also, as group size increases the limitation as group size grows. Also, as group size increases the
frequency of reports from each receiver decreases, which further frequency of reports from each receiver decreases, which further
reduces the responsiveness of the mechanism. Receiver-driven reduces the responsiveness of the mechanism. Receiver-driven
congestion control has the advantage that each receiver can choose congestion control has the advantage that each receiver can choose
the appropriate rate for its network path, rather than all having to the appropriate rate for its network path, rather than all having to
settle for the lowest common rate. settle for the lowest common rate.
We note that ECN support is not a silver bullet to improving We note that ECN support is not a silver bullet to improving
performance. The use of ECN gives the chance to respond to performance. The use of ECN gives the chance to respond to
congestion before packets are dropped in the network, improving the congestion before packets are dropped in the network, improving the
user experience by allowing the RTP application to control how the user experience by allowing the RTP application to control how the
quality is reduced. An application which ignores ECN congestion quality is reduced. An application which ignores ECN Congestion
experienced feedback is not immune to congestion: the network will Experienced feedback is not immune to congestion: the network will
eventually begin to discard packets if traffic doesn't respond. It eventually begin to discard packets if traffic doesn't respond. It
is in the best interest of an application to respond to ECN is in the best interest of an application to respond to ECN
congestion feedback promptly, to avoid packet loss. congestion feedback promptly, to avoid packet loss.
7.4. Detecting Failures 7.4. Detecting Failures
Senders and receivers can deliberately ignore ECN-CE and thus get a Senders and receivers can deliberately ignore ECN-CE and thus get a
benefit over behaving flows (cheating). Nonce [RFC3540] is an benefit over behaving flows (cheating). Th ECN Nonce [RFC3540] is an
addition to TCP that solves this issue as long as the sender acts on addition to TCP that attempts to solve this issue as long as the
behalf of the network. The assumption about the senders acting on sender acts on behalf of the network. The assumption about the
the behalf of the network may be reduced due to the nature of peer- senders acting on the behalf of the network may be reduced due to the
to-peer use of RTP. Still a significant portion of RTP senders are nature of peer-to-peer use of RTP. Still a significant portion of
infrastructure devices (for example, streaming media servers) that do RTP senders are infrastructure devices (for example, streaming media
have an interest in protecting both service quality and the network. servers) that do have an interest in protecting both service quality
Even though there may be cases where nonce can be applicable also for and the network. Even though there may be cases where nonce can be
RTP, it is not included in this specification. This as a receiver applicable also for RTP, it is not included in this specification.
interested in cheating would simple claim to not support Nonce. It This as a receiver interested in cheating would simple claim to not
is however worth mention that, as real-time media is commonly support nonce, or even ECN itself. It is however worth mentioning
sensitive to increased delay and packet loss, it will be in both that, as real-time media is commonly sensitive to increased delay and
media sender and receivers interest to minimise the number and packet loss, it will be in both the media sender and receivers
duration of any congestion events as they will affect media quality. 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 RTP sessions can also suffer from path changes resulting in a non-ECN
compliant node becoming part of the path. That node may perform compliant node becoming part of the path. That node may perform
either of two actions that has effect on the ECN and application either of two actions that has effect on the ECN and application
functionality. The gravest is if the node drops packets with any ECN functionality. The gravest is if the node drops packets with the ECN
field values other than 00b. This can be detected by the receiver field set to ECT(0), ECT(1), or CE. This can be detected by the
when it receives a RTCP SR packet indicating that a sender has sent a receiver when it receives an RTCP SR packet indicating that a sender
number of packets has not been received. The sender may also detect has sent a number of packets that it has not received. The sender
it based on the receivers RTCP RR packet where the extended sequence may also detect it based on the receivers RTCP RR packet where the
number is not advanced due to the failure to receive packets. If the extended sequence number is not advanced due to the failure to
packet loss is less than 100% then packet loss reporting in either receive packets. If the packet loss is less than 100% then packet
the ECN feedback information or RTCP RR will indicate the situation. loss reporting in either the ECN feedback information or RTCP RR will
The other action is to re-mark a packet from ECT or CE to not-ECT. indicate the situation. The other action is to re-mark a packet from
That has less dire results, however, it should be detected so that ECT or CE to not-ECT. That has less dire results, however, it should
ECN usage can be suspended to prevent misusing the network. be detected so that ECN usage can be suspended to prevent misusing
the network.
The ECN feedback packet allows the sender to compare the number of The RTCP XR ECN summary packet and the ECN feedback packet allow the
ECT marked packets of different type with the number it actually sender to compare the number of ECT marked packets of different types
sent. The number of ECT packets received plus the number of CE received with the number it actually sent. The number of ECT packets
marked and lost packets should correspond to the number of sent ECT received plus the number of CE marked and lost packets should
marked packets unless there is duplication in the network. If this correspond to the number of sent ECT marked packets plus the number
number doesn't agree there are two likely reasons, a translator of received duplicates. If these numbers doesn't agree there are two
changing the stream or not carrying the ECN markings forward, or that likely reasons, a translator changing the stream or not carrying the
some node re-marks the packets. In both cases the usage of ECN is ECN markings forward, or that some node re-marks the packets. In
broken on the path. By tracking all the different possible ECN field both cases the usage of ECN is broken on the path. By tracking all
values a sender can quickly detect if some non-compliant behavior is the different possible ECN field values a sender can quickly detect
happing on the path. if some non-compliant behavior is happing on the path.
Thus packet losses and non-matching ECN field value statistics are Thus packet losses and non-matching ECN field value statistics are
possible indication of issues with using ECN over the path. The next possible indication of issues with using ECN over the path. The next
section defines both sender and receiver reactions to these cases. section defines both sender and receiver reactions to these cases.
7.4.1. Fallback mechanisms 7.4.1. Fallback mechanisms
Upon the detection of a potential failure both the sender and the Upon the detection of a potential failure both the sender and the
receiver can react to mitigate the situation. receiver can react to mitigate the situation.
A receiver that detects a packet loss burst MAY schedule an early A receiver that detects a packet loss burst MAY schedule an early
feedback packet to report this to the sender that includes at least feedback packet that includes at least the RTCP RR and the ECN
the RTCP RR and the ECN feedback message. Thus speeding up the feedback message to report this to the sender. This will speed up
detection at the sender of the losses and thus triggering sender side the detection at the sender of the losses and thus triggering sender
mitigation. side mitigation.
A sender that detects high packet loss rates for ECT-marked packets A sender that detects high packet loss rates for ECT-marked packets
SHOULD immediately switch to sending packets as not-ECT to determine SHOULD immediately switch to sending packets as not-ECT to determine
if the losses potentially are due to the ECT markings. If the losses if the losses potentially are due to the ECT markings. If the losses
disappear when the ECT-marking is discontinued, the RTP sender should disappear when the ECT-marking is discontinued, the RTP sender should
go back to initiation procedures to attempt to verify the apparent go back to initiation procedures to attempt to verify the apparent
loss of ECN capability of the used path. If a re-initiation fails loss of ECN capability of the used path. If a re-initiation fails
then the two possible actions exist: then the two possible actions exist:
1. Periodically retry the ECN initiation to detect if a path change 1. Periodically retry the ECN initiation to detect if a path change
skipping to change at page 37, line 14 skipping to change at page 38, line 18
cause problems for ECN. cause problems for ECN.
7.4.2. Interpretation of ECN Summary information 7.4.2. Interpretation of ECN Summary information
This section contains discussion on how you can use the ECN summary This section contains discussion on how you can use the ECN summary
report information in detecting various types of ECN path issues. report information in detecting various types of ECN path issues.
Lets start to review the information the reports provide on a per Lets start to review the information the reports provide on a per
source (SSRC) basis: source (SSRC) basis:
CE Counter: The number of RTP packets received so far in the session CE Counter: The number of RTP packets received so far in the session
with an ECN field set to CE (11b). with an ECN field set to CE.
ECT (0/1) Counters: The number of RTP packets received so far in the ECT (0/1) Counters: The number of RTP packets received so far in the
session with an ECN field set to ECT (0) and ECT (1) respectively session with an ECN field set to ECT (0) and ECT (1) respectively.
(10b / 01b).
not-ECT Counter: The number of RTP packets received so far in the not-ECT Counter: The number of RTP packets received so far in the
session with an ECN field set to not-ECT (00b) session with an ECN field set to not-ECT.
Lost Packets counter: The number of RTP packets that are expected Lost Packets counter: The number of RTP packets. that where expected
minus the number received. 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 Extended Highest Sequence number: The highest sequence number seen
when sending this report, but with additional bits, to handle when sending this report, but with additional bits, to handle
disambiguation when wrapping the RTP sequence number field. disambiguation when wrapping the RTP sequence number field.
The counters will be initiated to zero to provide value for the RTP The counters will be initiated to zero to provide value for the RTP
stream sender from the very first report. After the first report the stream sender from the very first report. After the first report the
changes between the latest received and the previous one is changes between the latest received and the previous one is
determined by simply taking the values of the latest minus the determined by simply taking the values of the latest minus the
previous one, taking field wrapping into account. This definition is previous one, taking field wrapping into account. This definition is
skipping to change at page 37, line 48 skipping to change at page 39, line 6
In a perfect world the number of not-ECT packets received should be 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 equal to the number sent minus the lost packets counter, and the sum
of the ECT(0), ECT(1), and CE counters should be equal to the number of the ECT(0), ECT(1), and CE counters should be equal to the number
of ECT marked packet sent. Two issues may cause a mismatch in these of ECT marked packet sent. Two issues may cause a mismatch in these
statistics: severe network congestion or unresponsive congestion statistics: severe network congestion or unresponsive congestion
control might cause some ECT-marked packets to be lost, and packet control might cause some ECT-marked packets to be lost, and packet
duplication might result in some packets being received, and counted duplication might result in some packets being received, and counted
in the statistics, multiple times (potentially with a different ECN- in the statistics, multiple times (potentially with a different ECN-
mark on each copy of the duplicate). mark on each copy of the duplicate).
The level of packet duplication included in the report can be The rate of duplication is tracked, allowing one to take the
estimated from the sum over all of fields counting received packets duplication into account. The value of the ECN field for duplicates
compared to the number of packets sent. A high level of packet will also be counted and when comparing the figures one needs to take
duplication increases the uncertainty in the statistics, making it some fraction of packet duplicates that are non-ECT and some fraction
more difficult to draw firm conclusions about the behaviour of the of packet duplicates being ECT into account into the calculation.
network. This issue is also present with standard RTCP reception Thus when only sending non-ECT then the number of sent packets plus
reports. 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), 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. More on packet loss below.
Detecting clearing of ECN field: If the ratio between ECT and not-ECT Detecting clearing of ECN field: If the ratio between ECT and not-ECT
transmitted in the reports has become all not-ECT or substantially transmitted in the reports has become all not-ECT or substantially
changed towards not-ECT then this is clearly indication that the path changed towards not-ECT then this is clearly indication that the path
results in clearing of the ECT field. results in clearing of the ECT field.
Dropping of ECT packets: To determine if the packet drop ratio is Dropping of ECT packets: To determine if the packet drop ratio is
different between not-ECT and ECT marked transmission requires a mix different between not-ECT and ECT marked transmission requires a mix
of transmitted traffic. The sender should compare if the delivery of transmitted traffic. The sender should compare if the delivery
percentage (delivered / transmitted) between ECT and not-ECT is percentage (delivered / transmitted) between ECT and not-ECT is
significantly different. Care must be taken if the number of packets significantly different. Care must be taken if the number of packets
are low in either of the categories. One must also take into account 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 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 unless it was ECT marked. Thus, the packet loss level for not-ECT
should be aprroximately equal to the loss rate for ECT when counting should be approximately equal to the loss rate for ECT when counting
the CE marked packets as lost ones. A sender performing this the CE marked packets as lost ones. A sender performing this
calculation needs to ensure that the difference is statistcally calculation needs to ensure that the difference is statistically
significant. significant.
If erronous behavior is detected, it should be logged to enable If erroneous behavior is detected, it should be logged to enable
follow up and statistics gathering. follow up and statistics gathering.
8. Processing RTCP ECN Feedback in RTP Translators and Mixers 8. Processing ECN in RTP Translators and Mixers
RTP translators and mixers that support ECN feedback are required to RTP translators and mixers that support ECN for RTP are required to
process, and potentially modify or generate, RTCP packets for the process, and potentially modify or generate ECN marking in RTP
translated and/or mixed streams. This includes both downstream RTCP packets. They also need to process, and potentially modify or
reports generated by the media sender, and also reports generated by generate RTCP ECN feedback packets for the translated and/or mixed
the receivers, flowing upstream back towards the sender. 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.
8.1. Fragmentation and Reassembly in Translators 8.1. Transport Translators
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.
8.2. Fragmentation and Reassembly in Translators
An RTP translator may fragment or reassemble RTP data packets without An RTP translator may fragment or reassemble RTP data packets without
changing the media encoding, and without reference to the congestion changing the media encoding, and without reference to the congestion
state of the networks it bridges. An example of this might be to 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 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, per RTP packet into new RTP packets with two 20ms frames per packet,
thereby reducing the header overheads and so stream bandwidth, at the thereby reducing the header overheads and so stream bandwidth, at the
expense of an increase in latency. If multiple data packets are re- expense of an increase in latency. If multiple data packets are re-
encoded into one, or vice versa, the RTP translator MUST assign new encoded into one, or vice versa, the RTP translator MUST assign new
sequence numbers to the outgoing packets. Losses in the incoming RTP sequence numbers to the outgoing packets. Losses in the incoming RTP
packet stream may also induce corresponding gaps in the outgoing RTP packet stream may also induce corresponding gaps in the outgoing RTP
sequence numbers. An RTP translator MUST rewrite RTCP packets to sequence numbers. An RTP translator MUST rewrite RTCP packets to
make the corresponding changes to their sequence numbers, and to make the corresponding changes to their sequence numbers, and to
reflect the impact of the fragmentation or reassembly. This section reflect the impact of the fragmentation or reassembly. This section
describes how that rewriting is to be done for RTCP ECN feedback describes how that rewriting is to be done for RTCP ECN feedback
packets. Section 7.2 of [RFC3550] describes general procedures for packets. Section 7.2 of [RFC3550] describes general procedures for
other RTCP packet types. other RTCP packet types.
RTCP ECN feedback packets (Section 5.1) contain six fields that are 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: rewritten in an RTP translator that fragments or reassembles packets:
the extended highest sequence number, the lost packets counter, the the extended highest sequence number, the duplication counter, the
CE counter, and not-ECT counter, the ECT(0) counter, and the ECT(1) lost packets counter, the CE counter, and not-ECT counter, the ECT(0)
counter. The RTCP XR report block for ECN summary information counter, and the ECT(1) counter. The RTCP XR report block for ECN
(Section 5.2) includes a subset of these fields excluding the summary information (Section 5.2) includes all of these fields except
extended highest sequence number and lost packets counter. The the extended highest sequence number which is present in the report
procedures for rewriting these fields are the same for both types of block in an SR or RR packet. The procedures for rewriting these
RTCP ECN feedback packet. fields are the same for both RTCP ECN feedback packet and the XR ECN
summary packet.
When receiving an RTCP ECN feedback packet for the translated stream, When receiving an RTCP ECN feedback packet for the translated stream,
an RTP translator first determines the range of packets to which the an RTP translator first determines the range of packets to which the
report corresponds. The extended highest sequence number in the RTCP report corresponds. The extended highest sequence number in the RTCP
ECN feedback packet (or in the RTCP SR/RR packet contained within the ECN feedback packet (or in the RTCP SR/RR packet contained within the
compound packet, in the case of RTCP XR ECN summary reports) compound packet, in the case of RTCP XR ECN summary reports)
specifies the end sequence number of the range. For the first RTCP specifies the end sequence number of the range. For the first RTCP
ECN feedback packet received, the initial extended sequence number of ECN feedback packet received, the initial extended sequence number of
the range may be determined by subtracting the sum of the lost the range may be determined by subtracting the sum of the lost
packets counter, the CE counter, the not-ECT counter, the ECT(0) packets counter, the CE counter, the not-ECT counter, the ECT(0)
counter and the ECT(1) counter from the extended highest sequence counter and the ECT(1) counter minus the duplication counter, from
number (this will be inaccurate if there is packet duplication). For the extended highest sequence number. For subsequent RTCP ECN
subsequent RTCP ECN feedback packets, the starting sequence number feedback packets, the starting sequence number may be determined as
may be determined as being one after the extended highest sequence being one after the extended highest sequence number of the previous
number of the previous RTCP ECN feedback packet received from the RTCP ECN feedback packet received from the same SSRC. These values
same SSRC. These values are in the sequence number space of the are in the sequence number space of the translated packets.
translated packets.
Based on its knowledge of the translation process, the translator Based on its knowledge of the translation process, the translator
determines the sequence number range for the corresponding original, determines the sequence number range for the corresponding original,
pre-translation, packets. The extended highest sequence number in pre-translation, packets. The extended highest sequence number in
the RTCP ECN feedback packet is rewritten to match the final sequence the RTCP ECN feedback packet is rewritten to match the final sequence
number in the pre-translation sequence number range. number in the pre-translation sequence number range.
The translator then determines the ratio, R, of the number of packets The translator then determines the ratio, R, of the number of packets
in the translated sequence number space (numTrans) to the number of in the translated sequence number space (numTrans) to the number of
packets in the pre-translation sequence number space (numOrig) such packets in the pre-translation sequence number space (numOrig) such
skipping to change at page 40, line 25 skipping to change at page 42, line 21
translator should try to ensure that they sum to the number of RTP translator should try to ensure that they sum to the number of RTP
packets in the pre-translation sequence number space (numOrig). The packets in the pre-translation sequence number space (numOrig). The
translator should also try to ensure that no non-zero counter is translator should also try to ensure that no non-zero counter is
rounded to a zero value, since that will lose information that a rounded to a zero value, since that will lose information that a
particular type of event has occurred. It is recognised that it may particular type of event has occurred. It is recognised that it may
be impossible to satisfy both of these constraints; in such cases, it 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 is better to ensure that no non-zero counter is mapped to a zero
value, since this preserves congestion adaptation and helps the RTCP- value, since this preserves congestion adaptation and helps the RTCP-
based ECN initiation process. 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 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 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 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 likely to be a reasonable assumption in the type of environment where
RTP translators that fragment or reassemble packets are deployed, as RTP translators that fragment or reassemble packets are deployed, as
their entire purpose is to change the number of packets being sent to their entire purpose is to change the number of packets being sent to
adapt to known limitations of the network, but is not necessarily adapt to known limitations of the network, but is not necessarily
valid in general. valid in general.
The rewritten RTCP ECN feedback report is sent from the other side of 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 the translator to that which it arrived (as part of a compound RTCP
packet containing other translated RTCP packets, where appropriate). packet containing other translated RTCP packets, where appropriate).
8.2. Generating RTCP ECN Feedback in Media Transcoders 8.3. Generating RTCP ECN Feedback in Media Transcoders
An RTP translator that acts as a media transcoder cannot directly An RTP translator that acts as a media transcoder cannot directly
forward RTCP packets corresponding to the transcoded stream, since forward RTCP packets corresponding to the transcoded stream, since
those packets will relate to the non-transcoded stream, and will not those packets will relate to the non-transcoded stream, and will not
be useful in relation to the transcoded RTP flow. Such a transcoder 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 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 for the receiver to generate RTCP feedback in the direction of the
sender relating to the pre-transcoded stream, and acting in place of sender relating to the pre-transcoded stream, and acting in place of
the sender to generate RTCP relating to the transcoded stream, to be the sender to generate RTCP relating to the transcoded stream, to be
sent towards the receiver. This section describes how this proxying sent towards the receiver. This section describes how this proxying
skipping to change at page 41, line 27 skipping to change at page 43, line 31
An RTP translator acting as a media transcoder will generate RTCP An RTP translator acting as a media transcoder will generate RTCP
reports upstream towards the original media sender, based on the reports upstream towards the original media sender, based on the
reception quality of the original media stream at the translator. reception quality of the original media stream at the translator.
The translator will run a separate congestion control loop and media The translator will run a separate congestion control loop and media
adaptation between itself and the media sender for each of its adaptation between itself and the media sender for each of its
downstream receivers, and must generate RTCP ECN feedback packets and downstream receivers, and must generate RTCP ECN feedback packets and
RTCP XR ECN summary reports for that congestion control loop using RTCP XR ECN summary reports for that congestion control loop using
the SSRC of that downstream receiver. the SSRC of that downstream receiver.
8.3. Generating RTCP ECN Feedback in Mixers 8.4. Generating RTCP ECN Feedback in Mixers
An RTP mixer terminates one-or-more RTP flows, combines them into a An RTP mixer terminates one-or-more RTP flows, combines them into a
single outgoing media stream, and transmits that new stream as 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 separate RTP flow. A mixer has its own SSRC, and is visible to other
participants in the session at the RTP layer. participants in the session at the RTP layer.
An ECN-aware RTP mixer must generate RTCP ECN feedback packets and An ECN-aware RTP mixer must generate RTCP ECN feedback packets and
RTCP XR report blocks for ECN summary information relating to the RTP 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 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 RTP receiver. These reports form part of the congestion control loop
between the mixer and the media senders generating the streams it is between the mixer and the media senders generating the streams it is
mixing. A separate control loop runs between each sender and the mixing. A separate control loop runs between each sender and the
mixer. mixer.
An ECN-aware RTP mixer will negotiate and initiate the use of ECN on An ECN-aware RTP mixer will negotiate and initiate the use of ECN on
the mixed flows it generates, and will accept and process RTCP ECN the mixed RTP flows it generates, and will accept and process RTCP
feedback reports and RTCP XR report blocks for ECN relating to those ECN feedback reports and RTCP XR report blocks for ECN relating to
mixed flows as if it were a standard media sender. A congestion those mixed flows as if it were a standard media sender. A
control loop runs between the mixer and its receivers, driven in part congestion control loop runs between the mixer and its receivers,
by the ECN reports received. driven in part by the ECN reports received.
An RTP mixer MUST NOT forward RTCP ECN feedback packets or RTCP XR An RTP mixer MUST NOT forward RTCP ECN feedback packets or RTCP XR
ECN summary reports reports from downstream receivers in the upstream ECN summary reports from downstream receivers in the upstream
direction. direction.
9. Implementation considerations 9. Implementation considerations
To allow the use of ECN with RTP over UDP, the RTP implementation To allow the use of ECN with RTP over UDP, the RTP implementation
must be able to set the ECT bits in outgoing UDP datagrams, and must should be able to set the ECT bits in outgoing UDP datagrams, and
be able to read the value of the ECT bits on received UDP datagrams. should be able to read the value of the ECT bits on received UDP
The standard Berkeley sockets API pre-dates the specification of ECN, datagrams. The standard Berkeley sockets API pre-dates the
and does not provide the functionality which is required for this specification of ECN, and does not provide the functionality which is
mechanism to be used with UDP flows, making this specification required for this mechanism to be used with UDP flows, making this
difficult to implement portably. specification difficult to implement portably.
10. IANA Considerations 10. IANA Considerations
Note to RFC Editor: please replace "RFC XXXX" below with the RFC Note to RFC Editor: please replace "RFC XXXX" below with the RFC
number of this memo, and remove this note. number of this memo, and remove this note.
10.1. SDP Attribute Registration 10.1. SDP Attribute Registration
Following the guidelines in [RFC4566], the IANA is requested to Following the guidelines in [RFC4566], the IANA is requested to
register one new SDP attribute: register one new SDP attribute:
skipping to change at page 42, line 35 skipping to change at page 44, line 39
o Contact name, email address and telephone number: Authors of o Contact name, email address and telephone number: Authors of
RFCXXXX RFCXXXX
o Attribute-name: ecn-capable-rtp o Attribute-name: ecn-capable-rtp
o Type of attribute: media-level o Type of attribute: media-level
o Subject to charset: no o Subject to charset: no
This attribute defines the ability to negotiate the use of ECT (ECN This attribute defines the ability to negotiate the use of ECT (ECN
capable transport). This attribute should be put in the SDP offer if capable transport) for RTP flows running over UDP/IP. This attribute
the offering party wishes to receive an ECT flow. The answering should be put in the SDP offer if the offering party wishes to
party should include the attribute in the answer if it wish to receive an ECT flow. The answering party should include the
receive an ECT flow. If the answerer does not include the attribute attribute in the answer if it wish to receive an ECT flow. If the
then ECT MUST be disabled in both directions. answerer does not include the attribute then ECT MUST be disabled in
both directions.
10.2. RTP/AVPF Transport Layer Feedback Message 10.2. RTP/AVPF Transport Layer Feedback Message
The IANA is requested to register one new RTP/AVPF Transport Layer The IANA is requested to register one new RTP/AVPF Transport Layer
Feedback Message in the table of FMT values for RTPFB Payload Types Feedback Message in the table of FMT values for RTPFB Payload Types
[RFC4585] as defined in Section 5.1: [RFC4585] as defined in Section 5.1:
Name: RTCP-ECN-FB Name: RTCP-ECN-FB
Long name: RTCP ECN Feedback Long name: RTCP ECN Feedback
Value: TBA1 Value: TBA1
skipping to change at page 43, line 51 skipping to change at page 46, line 8
10.7. ICE Option 10.7. ICE Option
A new ICE option "rtp+ecn" is registered in the registry that "IANA A new ICE option "rtp+ecn" is registered in the registry that "IANA
Registry for Interactive Connectivity Establishment (ICE) Options" Registry for Interactive Connectivity Establishment (ICE) Options"
[I-D.ietf-mmusic-ice-options-registry] creates. [I-D.ietf-mmusic-ice-options-registry] creates.
11. Security Considerations 11. Security Considerations
The usage of ECN with RTP over UDP as specified in this document has The usage of ECN with RTP over UDP as specified in this document has
the following known security issues that needs to be considered. the following known security issues that need to be considered.
External threats to the RTP and RTCP traffic: External threats to the RTP and RTCP traffic:
Denial of Service affecting RTCP: For an attacker that can modify Denial of Service affecting RTCP: For an attacker that can modify
the traffic between the media sender and a receiver can achieve the traffic between the media sender and a receiver can achieve
either of two things. 1. Report a lot of packets as being either of two things: 1) Report a lot of packets as being
Congestion Experience marked, thus forcing the sender into a Congestion Experience marked, thus forcing the sender into a
congestion response. 2. Ensure that the sender disable the usage congestion response; or 2) Ensure that the sender disable the
of ECN by reporting failures to receive ECN by changing the usage of ECN by reporting failures to receive ECN by changing the
counter fields. The Issue, can also be accomplished by injecting counter fields. This can also be accomplished by injecting false
false RTCP packets to the media sender. Reporting a lot of CE RTCP packets to the media sender. Reporting a lot of CE marked
marked traffic is likely the more efficient denial of service tool traffic is likely the more efficient denial of service tool as
as that may likely force the application to use lowest possible that may likely force the application to use lowest possible bit-
bit-rates. The prevention against an external threat is to rates. The prevention against an external threat is to integrity
integrity protect the RTCP feedback information and authenticate protect the RTCP feedback information and authenticate the sender
the sender of it. of it.
Information leakage: The ECN feedback mechanism exposes the Information leakage: The ECN feedback mechanism exposes the
receivers perceived packet loss, what packets it considers to be receivers perceived packet loss, what packets it considers to be
ECN-CE marked and its calculation of the ECN-none. This is mostly ECN-CE marked and its calculation of the ECN-none. This is mostly
not considered sensitive information. If considered sensitive the not considered as sensitive information. If it is considered
RTCP feedback shall be encrypted. sensitive the RTCP feedback should be encrypted.
Changing the ECN bits An on-path attacker that see the RTP packet 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 flow from sender to receiver and who has the capability to change
the packets can rewrite ECT into ECN-CE thus forcing the sender or the packets can rewrite ECT into ECN-CE thus forcing the sender or
receiver to take congestion control response. This denial of receiver to take congestion control response. This denial of
service against the media quality in the RTP session is impossible service against the media quality in the RTP session is impossible
for en end-point to protect itself against. Only network for an end-point to protect itself against. Only network
infrastructure nodes can detect this illicit re-marking. It will infrastructure nodes can detect this illicit re-marking. It will
be mitigated by turning off ECN, however, if the attacker can be mitigated by turning off ECN, however, if the attacker can
modify its response to drop packets the same vulnerability exist. modify its response to drop packets the same vulnerability exist.
Denial of Service affecting the session set-up signalling: If an Denial of Service affecting the session set-up signalling: If an
attacker can modify the session signalling it can prevent the attacker can modify the session signalling it can prevent the
usage of ECN by removing the signalling attributes used to usage of ECN by removing the signalling attributes used to
indicate that the initiator is capable and willing to use ECN with indicate that the initiator is capable and willing to use ECN with
RTP/UDP. This attack can be prevented by authentication and RTP/UDP. This attack can be prevented by authentication and
integrity protection of the signalling. We do note that any integrity protection of the signalling. We do note that any
attacker that can modify the signalling has more interesting attacker that can modify the signalling has more interesting
attacks they can perform than prevent the usage of ECN, like attacks they can perform than prevent the usage of ECN, like
inserting itself as a middleman in the media flows enabling wire- inserting itself as a middleman in the media flows enabling wire-
tapping also for an off-path attacker. tapping also for an off-path attacker.
The following are threats that exist from misbehaving senders or The following are threats that exist from misbehaving senders or
receivers: receivers:
Receivers cheating A receiver may attempt to cheat and fail to Receivers cheating: A receiver may attempt to cheat and fail to
report reception of ECN-CE marked packets. The benefit for a report reception of ECN-CE marked packets. The benefit for a
receiver cheating in its reporting would be to get an unfair bit- receiver cheating in its reporting would be to get an unfair bit-
rate share across the resource bottleneck. It is far from certain rate share across the resource bottleneck. It is far from certain
that a receiver would be able to get a significant larger share of that a receiver would be able to get a significant larger share of
the resources. That assumes a high enough level of aggregation the resources. That assumes a high enough level of aggregation
that there are flows to acquire shares from. The risk of cheating that there are flows to acquire shares from. The risk of cheating
is that failure to react to congestion results in packet loss and is that failure to react to congestion results in packet loss and
increased path delay. increased path delay.
Receivers misbehaving: A receiver may prevent the usage of ECN in an Receivers misbehaving: A receiver may prevent the usage of ECN in an
RTP session by reporting itself as non ECN capable. Thus forcing RTP session by reporting itself as non ECN capable, forcing the
the sender to turn off usage of ECN. In a point-to-point scenario sender to turn off usage of ECN. In a point-to-point scenario
there is little incentive to do this as it will only affect the there is little incentive to do this as it will only affect the
receiver. Thus failing to utilise an optimisation. For multi- receiver. Thus failing to utilise an optimisation. For multi-
party session there exist some motivation why a receiver would party session there exist some motivation why a receiver would
misbehave as it can prevent also the other receivers from using misbehave as it can prevent also the other receivers from using
ECN. As an insider into the session it is difficult to determine ECN. As an insider into the session it is difficult to determine
if a receiver is misbehaving or simply incapable, making it if a receiver is misbehaving or simply incapable, making it
basically impossible in the incremental deployment phase of ECN basically impossible in the incremental deployment phase of ECN
for RTP usage to determine this. If additional information about for RTP usage to determine this. If additional information about
the receivers and the network is known it might be possible to the receivers and the network is known it might be possible to
deduce that a receiver is misbehaving. If it can be determined deduce that a receiver is misbehaving. If it can be determined
that a receiver is misbehaving, the only response is to exclude it that a receiver is misbehaving, the only response is to exclude it
from the RTP session and ensure that is doesn't any longer have from the RTP session and ensure that is does not any longer have
any valid security context to affect the session. any valid security context to affect the session.
Misbehaving Senders: The enabling of ECN gives the media packets a Misbehaving Senders: The enabling of ECN gives the media packets a
higher degree of probability to reach the receiver compared to higher degree of probability to reach the receiver compared to
not-ECT marked ones on a ECN capable path. However, this is no not-ECT marked ones on a ECN capable path. However, this is no
magic bullet and failure to react to congestion will most likely magic bullet and failure to react to congestion will most likely
only slightly delay a buffer under-run, in which its session also only slightly delay a network buffer over-run, in which its
will experience packet loss and increased delay. There are some session also will experience packet loss and increased delay.
chance that the media senders traffic will push other traffic out There is some possibility that the media senders traffic will push
of the way without being effected to negatively. However, we do other traffic out of the way without being affected too
note that a media sender still needs to implement congestion negatively. However, we do note that a media sender still needs
control functions to prevent the media from being badly affected to implement congestion control functions to prevent the media
by congestion events. Thus the misbehaving sender is getting a from being badly affected by congestion events. Thus the
unfair share. This can only be detected and potentially prevented misbehaving sender is getting a unfair share. This can only be
by network monitoring and administrative entities. See Section 7 detected and potentially prevented by network monitoring and
of [RFC3168] for more discussion of this issue. administrative entities. See Section 7 of [RFC3168] for more
discussion of this issue.
We note that the end-point security functions needs to prevent an We note that the end-point security functions needed to prevent an
external attacker from affecting the solution easily are source external attacker from inferring with the signalling are source
authentication and integrity protection. To prevent what information authentication and integrity protection. To prevent information
leakage there can be from the feedback encryption of the RTCP is also leakage from the feedback packets encryption of the RTCP is also
needed. For RTP there exist multiple solutions possible depending on needed. For RTP there exist multiple solutions possible depending on
the application context. Secure RTP (SRTP) [RFC3711] does satisfy the application context. Secure RTP (SRTP) [RFC3711] does satisfy
the requirement to protect this mechanism despite only providing the requirement to protect this mechanism despite only providing
authentication if a entity is within the security context or not. authentication if a entity is within the security context or not.
IPsec [RFC4301] and DTLS [RFC4347] can also provide the necessary IPsec [RFC4301] and DTLS [RFC4347] can also provide the necessary
security functions. security functions.
The signalling protocols used to initiate an RTP session also needs The signalling protocols used to initiate an RTP session also need to
to be source authenticated and integrity protected to prevent an be source authenticated and integrity protected to prevent an
external attacker from modifying any signalling. Here an appropriate external attacker from modifying any signalling. Here an appropriate
mechanism to protect the used signalling needs to be used. For SIP/ mechanism to protect the used signalling needs to be used. For SIP/
SDP ideally S/MIME [RFC5751] would be used. However, with the SDP ideally S/MIME [RFC5751] would be used. However, with the
limited deployment a minimal mitigation strategy is to require use of limited deployment a minimal mitigation strategy is to require use of
SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least accomplish hop- SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least accomplish hop-
by-hop protection. by-hop protection.
We do note that certain mitigation methods will require network We do note that certain mitigation methods will require network
functions. functions.
12. Examples of SDP Signalling 12. Examples of SDP Signalling
This section contain a few different examples of the signalling This section contain a few different examples of the signalling
mechanism defined in this specification in an SDP context. If there mechanism defined in this specification in an SDP context. If there
is discrepancies between these examples and the specification text, are discrepancies between these examples and the specification text,
the specification text is what is correct. the specification text is definitive.
12.1. Basic SDP Offer/Answer 12.1. Basic SDP Offer/Answer
This example is a basic offer/answer SDP exchange, assumed done by This example is a basic offer/answer SDP exchange, assumed done by
SIP (not shown). The intention is to establish a basic audio session SIP (not shown). The intention is to establish a basic audio session
point to point between two users. point to point between two users.
The Offer: The Offer:
v=0 v=0
skipping to change at page 47, line 29 skipping to change at page 49, line 29
a=fmtp:97 maxred=160 a=fmtp:97 maxred=160
a=rtpmap:98 AMR-WB/16000/1 a=rtpmap:98 AMR-WB/16000/1
a=fmtp:98 octet-align=1; mode-change-capability=2 a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 PCMA/8000/1 a=rtpmap:99 PCMA/8000/1
a=maxptime:160 a=maxptime:160
a=ptime:20 a=ptime:20
a=ecn-capable-rtp: ice rtp ect=0 mode=setread a=ecn-capable-rtp: ice rtp ect=0 mode=setread
a=rtcp-fb:* nack ecn a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1000 a=rtcp-fb:* trr-int 1000
a=rtcp-xr:ecn-sum a=rtcp-xr:ecn-sum
a=rtcp-rsize
a=candidate:1 1 UDP 2130706431 10.0.1.4 8998 typ host 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 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.4 rport 8998 10.0.1.4 rport 8998
This SDP offer offers a single media stream with 3 media payload This SDP offer offers a single media stream with 3 media payload
types. It proposes to use ECN with RTP, with the ICE based types. It proposes to use ECN with RTP, with the ICE based
initilziation as being prefered over the RTP/RTCP one. Leap of faith initialization as being preferred over the RTP/RTCP one. Leap of
is not suggested to be used. The offerer is capable of both setting faith is not suggested to be used. The offerer is capable of both
and reading the ECN bits. In addition the RTCP ECN feedback packet setting and reading the ECN bits. In addition the RTCP ECN feedback
is configured and the RTCP XR ECN summary report. ICE is also packet is configured and the RTCP XR ECN summary report. ICE is also
proposed with two candidates. proposed with two candidates. It also supports reduced size RTCP and
are willing to use it.
The Answer: The Answer:
v=0 v=0
o=jdoe 3502844783 3502844783 IN IP4 198.51.100.235 o=jdoe 3502844783 3502844783 IN IP4 198.51.100.235
s=VoIP call s=VoIP call
i=SDP offer for VoIP call with ICE and ECN for RTP i=SDP offer for VoIP call with ICE and ECN for RTP
b=AS:128 b=AS:128
b=RR:2000 b=RR:2000
b=RS:2500 b=RS:2500
skipping to change at page 48, line 31 skipping to change at page 50, line 31
a=maxptime:160 a=maxptime:160
a=ptime:20 a=ptime:20
a=ecn-capable-rtp: ice ect=0 mode=readonly a=ecn-capable-rtp: ice ect=0 mode=readonly
a=rtcp-fb:* nack ecn a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1000 a=rtcp-fb:* trr-int 1000
a=rtcp-xr:ecn-sum a=rtcp-xr:ecn-sum
a=candidate:1 1 UDP 2130706431 198.51.100.235 53879 typ host 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 The answer confirms that only one media stream will be used. One RTP
Payload type was removed. ECN capability was confirmed, and the Payload type was removed. ECN capability was confirmed, and the
initilization method will be ICE. However, the answerer is only initialization method will be ICE. However, the answerer is only
capable of reading the ECN bits, which means that ECN can only be 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 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 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. 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.
12.2. Declarative Multicast SDP 12.2. Declarative Multicast SDP
The below session describes an any source multicast using session The below session describes an any source multicast using session
with a single media stream. with a single media stream.
v=0 v=0
o=jdoe 3502844782 3502844782 IN IP4 198.51.100.235 o=jdoe 3502844782 3502844782 IN IP4 198.51.100.235
s=Multicast SDP session using ECN for RTP s=Multicast SDP session using ECN for RTP
i=Multicasted audio chat using ECN for RTP i=Multicasted audio chat using ECN for RTP
skipping to change at page 49, line 23 skipping to change at page 51, line 23
a=rtpmap:97 g719/48000/1 a=rtpmap:97 g719/48000/1
a=fmtp:97 maxred=160 a=fmtp:97 maxred=160
a=maxptime:160 a=maxptime:160
a=ptime:20 a=ptime:20
a=ecn-capable-rtp: rtp mode=readonly; ect=0 a=ecn-capable-rtp: rtp mode=readonly; ect=0
a=rtcp-fb:* nack ecn a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1500 a=rtcp-fb:* trr-int 1500
a=rtcp-xr:ecn-sum a=rtcp-xr:ecn-sum
In the above example, as this is declarative we need to require In the above example, as this is declarative we need to require
certain functionality. As it is ASM the initliziation method that certain functionality. As it is ASM the initialization method that
can work here is the RTP/RTCP based one. So that is indicated. The 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 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 least read. If one is capable of setting that is good, but not
required as one can skip using ECN for anything one send oneself. 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 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 this session requires both ECN feedback and the XR ECN summary
report, so their usage are also indicated. report, so their use is also indicated.
13. Open Issues 13. Open Issues
As this draft is under development some known open issues exist and As this draft is under development some known open issues exist and
are collected here. Please consider them and provide input. are collected here. Please consider them and provide input.
1. The negotiation and directionality attribute is going to need 1. The negotiation and directionality attribute is going to need
some consideration for multi-party sessions when readonly some consideration for multi-party sessions when readonly
capability might be sufficient to enable ECN for all incoming capability might be sufficient to enable ECN for all incoming
streams. However, it would beneficial to know if no potential streams. However, it would beneficial to know if no potential
skipping to change at page 50, line 24 skipping to change at page 52, line 24
Christian Groves, Cullen Jennings Tom Van Caenegem, Simo Christian Groves, Cullen Jennings Tom Van Caenegem, Simo
Veikkolainen, Lei Zhu, Christer Holmgren. Veikkolainen, Lei Zhu, Christer Holmgren.
15. References 15. References
15.1. Normative References 15.1. Normative References
[I-D.ietf-mmusic-ice-options-registry] [I-D.ietf-mmusic-ice-options-registry]
Westerlund, M. and C. Perkins, "IANA Registry for Westerlund, M. and C. Perkins, "IANA Registry for
Interactive Connectivity Establishment (ICE) Options", Interactive Connectivity Establishment (ICE) Options",
draft-ietf-mmusic-ice-options-registry-00 (work in draft-ietf-mmusic-ice-options-registry-02 (work in
progress), January 2011. progress), May 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2762] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group [RFC2762] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group
Membership in RTP", RFC 2762, February 2000. Membership in RTP", RFC 2762, February 2000.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
skipping to change at page 51, line 20 skipping to change at page 53, line 20
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
15.2. Informative References 15.2. Informative References
[I-D.ietf-avt-rtp-no-op] [I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP", Andreasen, F., "A No-Op Payload Format for RTP",
draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.
[I-D.zimmermann-avt-zrtp] [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media RFC 1112, August 1989.
Path Key Agreement for Unicast Secure RTP",
draft-zimmermann-avt-zrtp-22 (work in progress),
June 2010.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
skipping to change at page 52, line 22 skipping to change at page 54, line 19
Security", RFC 4347, April 2006. Security", RFC 4347, April 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. 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 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008. (RTP/SAVPF)", RFC 5124, February 2008.
skipping to change at page 53, line 5 skipping to change at page 54, line 48
Initiation Protocol (SIP)", RFC 5630, October 2009. Initiation Protocol (SIP)", RFC 5630, October 2009.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, January 2010. Specification", RFC 5751, January 2010.
[RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control
Protocol (RTCP) Extensions for Single-Source Multicast Protocol (RTCP) Extensions for Single-Source Multicast
Sessions with Unicast Feedback", RFC 5760, February 2010. 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.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE-164 80 Kista SE-164 80 Kista
Sweden Sweden
Phone: +46 10 714 82 87 Phone: +46 10 714 82 87
Email: magnus.westerlund@ericsson.com Email: magnus.westerlund@ericsson.com
 End of changes. 203 change blocks. 
744 lines changed or deleted 859 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/