draft-ietf-avtcore-ecn-for-rtp-02.txt   draft-ietf-avtcore-ecn-for-rtp-03.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: December 2, 2011 C. Perkins Expires: January 12, 2012 C. Perkins
University of Glasgow University of Glasgow
P. O'Hanlon P. O'Hanlon
UCL UCL
K. Carlberg K. Carlberg
G11 G11
May 31, 2011 July 11, 2011
Explicit Congestion Notification (ECN) for RTP over UDP Explicit Congestion Notification (ECN) for RTP over UDP
draft-ietf-avtcore-ecn-for-rtp-02 draft-ietf-avtcore-ecn-for-rtp-03
Abstract Abstract
This memo specifies how Explicit Congestion Notification (ECN) can be This memo specifies how Explicit Congestion Notification (ECN) can be
used with Real-time Transport Protocol (RTP) running over UDP, using used with the Real-time Transport Protocol (RTP) running over UDP,
RTP Control Protocol (RTCP) as a feedback mechanism. It defines a using RTP Control Protocol (RTCP) as a feedback mechanism. It
new RTCP Extended Report (XR) block for periodic ECN feedback, a new defines a new RTCP Extended Report (XR) block for periodic ECN
RTCP transport feedback message for timely reporting of congestion feedback, a new RTCP transport feedback message for timely reporting
events, and a Session Traversal Utilities for NAT (STUN) extension of congestion events, and a Session Traversal Utilities for NAT
used in the optional initilization method using Interactive (STUN) extension used in the optional initilization method using
Connectivity Establishment (ICE). Signalling and procedures for Interactive Connectivity Establishment (ICE). Signalling and
negotiation of capabilities and initilization methods are also procedures for negotiation of capabilities and initilization methods
defined. are also 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 December 2, 2011. This Internet-Draft will expire on January 12, 2012.
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 12 skipping to change at page 3, line 12
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 . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Interoperability . . . . . . . . . . . . . . . . . . . . . 11 3.3. Interoperability . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . 15 5.1. RTP/AVPF Transport Layer ECN Feedback packet . . . . . . . 15
5.2. RTCP XR Report block for ECN summary information . . . . . 18 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 ECN Feedback SDP Parameter . . . . . . . . . . . . . 25 6.2. RTCP ECN Feedback SDP Parameter . . . . . . . . . . . . . 25
6.3. XR Block ECN 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 . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . 33 7.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 33
7.4. Detecting Failures . . . . . . . . . . . . . . . . . . . . 36 7.4. Detecting Failures . . . . . . . . . . . . . . . . . . . . 36
8. Processing ECN in RTP Translators and Mixers . . . . . . . . . 39 8. Processing ECN in RTP Translators and Mixers . . . . . . . . . 40
8.1. Transport Translators . . . . . . . . . . . . . . . . . . 40 8.1. Transport Translators . . . . . . . . . . . . . . . . . . 40
8.2. Fragmentation and Reassembly in Translators . . . . . . . 40 8.2. Fragmentation and Reassembly in Translators . . . . . . . 40
8.3. Generating RTCP ECN Feedback in Media Transcoders . . . . 42 8.3. Generating RTCP ECN Feedback in Media Transcoders . . . . 42
8.4. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 43 8.4. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 43
9. Implementation considerations . . . . . . . . . . . . . . . . 44 9. Implementation considerations . . . . . . . . . . . . . . . . 44
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44
10.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 44 10.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 44
10.2. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 44 10.2. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 45
10.3. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 45 10.3. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 45
10.4. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 45 10.4. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 45
10.5. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 45 10.5. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 45
10.6. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 45 10.6. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 45
10.7. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 45 10.7. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 46
11. Security Considerations . . . . . . . . . . . . . . . . . . . 46 11. Security Considerations . . . . . . . . . . . . . . . . . . . 46
12. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 48 12. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 48
12.1. Basic SDP Offer/Answer . . . . . . . . . . . . . . . . . . 48 12.1. Basic SDP Offer/Answer . . . . . . . . . . . . . . . . . . 48
12.2. Declarative Multicast SDP . . . . . . . . . . . . . . . . 50 12.2. Declarative Multicast SDP . . . . . . . . . . . . . . . . 50
13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 51 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 51
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 14.1. Normative References . . . . . . . . . . . . . . . . . . . 51
15.1. Normative References . . . . . . . . . . . . . . . . . . . 52 14.2. Informative References . . . . . . . . . . . . . . . . . . 52
15.2. Informative References . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55
1. Introduction 1. Introduction
This memo 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 procedures for how verification of ECN functionality end-to-end, and procedures for how
to initiate ECN usage. The initiation process will have some to initiate ECN usage. Since the initiation process has some
dependencies on the signalling mechanism used to establish the RTP dependencies on the signalling mechanism used to establish the RTP
session, a specification for signalling mechanisms using Session session, a specification for signalling mechanisms using Session
Description 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. The use of ECN provides congestion on real-time multimedia traffic. The use of ECN provides
a way for the network to send a congestion control signal to a media a way for the network to send a congestion control signal to a media
transport without having to impair the media. Unlike packet loss, transport without having to impair the media. Unlike packet loss,
ECN signals unambiguously indicate congestion to the transport as ECN 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
skipping to change at page 5, line 15 skipping to change at page 5, line 15
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 and Definitions: Abbreviations and Definitions:
Sender: A sender of RTP packets carrying an encoded media stream. Sender: A sender of RTP packets carrying an encoded media stream.
The sender has the possibility to effect how this transmission is The sender can change how the media transmission is performed by
performed. It is one end-point of the ECN control loop. varying the media coding or packetisation. 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. It sends RTCP feedback on the received stream. the media stream. It sends RTCP feedback on the received stream.
It is the other end-point of the ECN control loop. It is the other end-point of the ECN control loop.
ECN Capable Host: A sender or receiver of a media stream that is ECN Capable Host: A sender or receiver of a media stream that is
capable of setting and/or processing ECN marks. capable of setting and/or processing ECN marks.
ECN Capable Transport (ECT): A transport flow where both sender and ECN Capable Transport (ECT): A transport flow where both sender and
receiver are ECN capable hosts. Packets sent by an ECN Capable receiver are ECN capable hosts. Packets sent by an ECN Capable
Transport will be marked as ECT(0) or ECT(1) on transmission. Transport will be marked as ECT(0) or ECT(1) on transmission. See
[RFC3168] for the definition of the ECT(0) and ECT(1) marks.
ECN-CE: ECN Congestion Experienced mark ECN-CE: ECN Congestion Experienced mark (see [RFC3168]).
ECN Capable Packets: Packets with ECN mark set to either ECT(0), ECN Capable Packets: Packets with ECN mark set to either ECT(0),
ECT(1) or ECN-CE. ECT(1) or ECN-CE.
Not-ECT packets: Packets that are not sent by an ECN capable Not-ECT packets: Packets that are not sent by an ECN capable
transport, and are not ECN-CE marked. transport, and are not ECN-CE marked.
ECN Oblivious Relay: A 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. Packets no differently from Not-ECT packets.
skipping to change at page 7, line 51 skipping to change at page 8, line 8
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 exist to negotiate and initiate the use of o REQ 1: A mechanism MUST exist to negotiate and initiate the use of
ECN for RTP/UDP/IP sessions so that an RTP sender will not send ECN for RTP/UDP/IP sessions so that an RTP sender will not send
packets with ECT in the IP header unless it knows that all packets with ECT in the IP header unless it knows that all
potential receivers will understand any CE indications they might potential receivers will understand any ECN-CE indications they
receive. might receive.
o REQ 2: A mechanism MUST exist to feed back the reception of any o REQ 2: A mechanism MUST exist to feed back the reception of any
packets that are ECN-CE marked to the packet sender. packets that are ECN-CE marked to the packet sender.
o REQ 3: The provided mechanism SHOULD minimise the possibility of o REQ 3: The provided mechanism SHOULD minimise the possibility of
cheating (either by the sender or receiver). 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.
skipping to change at page 8, line 37 skipping to change at page 8, line 43
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. The mechanisms defined with various different signalling protocols. The mechanisms defined
here make it possible to verify support for ECN in each of these here make it possible to verify support for ECN in each of these
environments, and irrespective of the topology. environments, and irrespective of the topology.
Due to the need for each RTP sender that intends 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 use of ECN is further dependent on a capability of the RTP media The use of ECN is further dependent on a capability of the RTP 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
skipping to change at page 9, line 30 skipping to change at page 9, line 33
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 its known receivers support ECN, verified that the paths to all its known receivers support ECN,
and 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 have not timed out). Note that reporting intervals, i.e., they have not timed out). Note that
group 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 check that all
receivers continue to support ECN, and they need to fallback to receivers, and the network paths traversed to reach those
non-ECN use if any senders do not. receivers, continue to support ECN, and they need to fallback to
non-ECN use if any receivers join that 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 that do not modify There are two types of RTP translator: those that do not modify
the 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
skipping to change at page 11, line 34 skipping to change at page 11, line 43
and receiver controlled congestion algorithms. The mechanism ensures and receiver controlled congestion algorithms. The mechanism ensures
that both senders and receivers will know about ECN-CE markings and that both senders and receivers will know about ECN-CE markings and
any packet losses. Thus the actual decision point for the congestion any packet losses. Thus the actual decision point for the congestion
control is not relevant. This is a great benefit as the rate of an control is not relevant. This is a great benefit as the rate of an
RTP session can be varied in a number of ways, for example a unicast RTP session can be varied in a number of ways, for example a unicast
media sender might use TFRC [RFC5348] or some other algorithm, while media sender might use TFRC [RFC5348] or some other algorithm, while
a multicast session could use a sender based scheme adapting to the a multicast session could use a sender based scheme adapting to the
lowest common supported rate, or a receiver driven mechanism using lowest common supported rate, or a receiver driven mechanism using
layered coding to support more heterogeneous paths. layered coding to support more heterogeneous paths.
To ensure timely feedback of CE marked packets when needed, this To ensure timely feedback of ECN-CE marked packets when needed, this
mechanism requires support for the RTP/AVPF profile [RFC4585] or any mechanism requires support for the RTP/AVPF profile [RFC4585] or any
of its derivatives, such as RTP/SAVPF [RFC5124]. The standard RTP/ of its derivatives, such as RTP/SAVPF [RFC5124]. The standard RTP/
AVP profile [RFC3551] does not allow any early or immediate AVP profile [RFC3551] does not allow any early or immediate
transmission of RTCP feedback, and has a minimal RTCP interval whose transmission of RTCP feedback, and has a minimal RTCP interval whose
default value (5 seconds) is many times the normal RTT between sender default value (5 seconds) is many times the normal RTT between sender
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
method that works in all cases, although is not optimal for all (Section 7.2.1) is the one method that works in all cases, although
usages, it is selected as mandatory to implement this initialisation is not optimal for all uses, it is selected as mandatory to implement
method. This method requires both the RTCP XR extension and the ECN this initialisation method. This method requires both the RTCP XR
feedback format, which requires the RTP/AVPF profile to ensure timely extension and the ECN feedback format, which require the RTP/AVPF
feedback. profile to ensure timely feedback.
When one considers all the uses of ECN for RTP it is clear that there When one considers all the uses of ECN for RTP it is clear that there
exist congestion control mechanisms that are receiver driven only exist congestion control mechanisms that are receiver driven only
(Section 7.3.3). These congestion control mechanism do not require (Section 7.3.3). These congestion control mechanism do not require
timely feedback of congestion events to the sender. If such a timely feedback of congestion events to the sender. If such a
congestion control mechanism is combined with an initialization congestion control mechanism is combined with an initialization
method that also doesn't require timely feedback using RTCP, like the method that also doesn't require timely feedback using RTCP, like the
leap of faith or the ICE based method then neither the ECN feedback leap of faith or the ICE based method then neither the ECN feedback
format nor the RTP/AVPF profile would appear to be needed. However, format nor the RTP/AVPF profile would appear to be needed. However,
fault detection can be greatly improved by using receiver side fault detection can be greatly improved by using receiver side
skipping to change at page 12, line 26 skipping to change at page 12, line 37
For interoperability we mandate the implementation of the RTP/AVPF For interoperability we mandate the implementation of the RTP/AVPF
profile, with both RTCP extensions and the necessary signalling to profile, with both RTCP extensions and the necessary signalling to
support a common operations mode. This specification recommends the support a common operations mode. This specification recommends the
use of RTP/AVPF in all cases as negotiation of the common use of RTP/AVPF in all cases as negotiation of the common
interoperability point requires RTP/AVPF, mixed negotiation of RTP/ interoperability point requires RTP/AVPF, mixed negotiation of RTP/
AVP and RTP/AVPF depending on other SDP attributes in the same media AVP and RTP/AVPF depending on other SDP attributes in the same media
block is difficult, and the fact that fault detection can be improved block is difficult, and the fact that fault detection can be improved
when using RTP/AVPF. when using RTP/AVPF.
The use of the ECN feedback format is also recommended but cases The use of the ECN feedback format is also recommended, but cases
where its usage is not required due to no need for timely feedback, exist where its use is not required due to no need for timely
that will be explicitly noted in the specification text. The term feedback. These will be explicitly noted using the term "no timely
"no timely feedback required" will be used to indicate usage that feedback required", and generally occur in combination with receiver
employs this specification in combination with receiver driven driven congestion control, and with the leap-of-faith and ICE-based
congestion control, and initialization methods that do not require initialization methods. We also note that any receiver driven
timely feedback, i.e. currently leap of faith and ICE based. We also congestion control solution that still requires RTCP for signalling
note that any receiver driven congestion control solution that still of any adaptation information to the sender will still require RTP/
requires RTCP for signalling of any adaptation information to the AVPF for timeliness.
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
skipping to change at page 14, line 19 skipping to change at page 14, line 30
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 an ECN-CE mark as
ECT. This could result in increased levels of congestion due to non- non-ECT. This could result in increased levels of congestion due to
responsiveness, and impact media quality as applications end up non-responsiveness, and impact media quality as applications end up
relying on packet loss as an indication of congestion. 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 feed back reports on any ECN-CE marks to the sender receivers rapidly feed back reports on any ECN-CE marks to the sender
using RTCP in RTP/AVPF immediate or early feedback mode, unless no using RTCP in RTP/AVPF immediate or early feedback mode, unless no
timely feedback is required. Each feedback report indicates the timely feedback is required. Each feedback report indicates the
receipt of new CE marks since the last ECN feedback packet, and also receipt of new ECN-CE marks since the last ECN feedback packet, and
counts the total number of CE marked packets as a cumulative sum. also counts the total number of ECN-CE marked packets as a cumulative
This is the mechanism to provide the fastest possible feedback to sum. This is the mechanism to provide the fastest possible feedback
senders about CE marks. On receipt of a CE marked packet, the system to senders about ECN-CE marks. On receipt of an ECN-CE marked
must react to congestion as-if packet loss has been reported. packet, the system must react to congestion as-if packet loss has
Section 7.3 describes the ongoing use of ECN within an RTP session. been reported. Section 7.3 describes the ongoing use of ECN within
an RTP session.
This rapid feedback is not optimised for reliability, so another This rapid feedback is not optimised for reliability, so another
mechanism, RTCP XR ECN summary reports, is used to ensure more mechanism, RTCP XR ECN summary reports, is used to ensure more
reliable, but less timely, reporting of the ECN information. The ECN reliable, but less timely, reporting of the ECN information. The ECN
summary report contains the same information as the ECN feedback summary report contains the same information as the ECN feedback
format, only packed differently for better efficiency with reports format, only packed differently for better efficiency with reports
for many sources. It is sent in a compound RTCP packet, along with for many sources. It is sent in a compound RTCP packet, along with
regular RTCP reception reports. By using cumulative counters for regular RTCP reception reports. By using cumulative counters for
observed CE, ECT, not-ECT, packet duplication, and packet loss the observed ECN-CE, ECT, not-ECT, packet duplication, and packet loss
sender can determine what events have happened since the last report, the sender can determine what events have happened since the last
independently of any RTCP packets having been lost. report, independently of any RTCP packets having been lost.
RTCP reports MUST NOT be ECT marked, since ECT marked traffic may be RTCP reports MUST NOT be ECT marked, since ECT marked traffic may be
dropped if the path is not ECN compliant. RTCP is used to provide dropped if the path is not ECN compliant. RTCP is used to provide
feedback about what has been transmitted and what ECN markings that feedback about what has been transmitted and what ECN markings that
are received, so it is important that it is received in cases when are received, so it is important that it is 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 (Section 7.4). Both the ECN is constantly monitored by all senders (Section 7.4). Both the
RTCP XR ECN summary reports and the ECN feedback packets allow the RTCP XR ECN summary reports and the ECN feedback packets allow the
sender to compare the number of ECT(0), ECT(1), and non-ECT marked sender to compare the number of ECT(0), ECT(1), and non-ECT marked
packets received with the number that were sent, while also reporting packets received with the number that were sent, while also reporting
CE marked and lost packets. If these numbers do not agree, it can be ECN-CE marked and lost packets. If these numbers do not agree, it
inferred that the path does not reliably pass ECN-marked packets. A can be inferred that the path does not reliably pass ECN-marked
sender detecting a possible ECN non-compliance issue should then stop packets. A sender detecting a possible ECN non-compliance issue
sending ECT marked packets to determine if that allows the packets to should then stop sending ECT marked packets to determine if that
be correctly delivered. If the issues can be connected to ECN, then allows the packets to be correctly delivered. If the issues can be
ECN usage is suspended. connected to ECN, then ECN usage is suspended.
5. RTCP Extensions for ECN feedback 5. RTCP Extensions for ECN feedback
This memo defines two new RTCP extensions: one RTP/AVPF [RFC4585] This memo defines two new RTCP extensions: one RTP/AVPF [RFC4585]
transport layer feedback format for urgent ECN information, and one transport layer feedback format for urgent ECN information, and one
RTCP XR [RFC3611] ECN summary report block type for regular reporting RTCP XR [RFC3611] ECN summary report block type for regular reporting
of the ECN marking information. of the ECN marking information.
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 use in This RTP/AVPF transport layer feedback format is intended for use in
RTP/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 reception
reception of an ECN-CE marked RTP packet so that the sender may of an ECN-CE marked RTP packet so that the sender may perform
perform congestion control, or to speed up the initiation procedures congestion control, or to speed up the initiation procedures by
by rapidly reporting that the path can support ECN-marked traffic. rapidly reporting that the path can support ECN-marked traffic. The
The feedback format is also defined with reduced size RTCP [RFC5506] feedback format is also defined with reduced size RTCP [RFC5506] in
in mind, where RTCP feedback packets may be sent without accompanying 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
in Figure 1. The FMT field takes the value [TBA1] to indicate that in Figure 1. The FMT field takes the value [TBA1] to indicate that
the Feedback Control Information (FCI) contains ECN Feedback report, the Feedback Control Information (FCI) contains ECN Feedback report,
as defined in Figure 2. as defined in Figure 2.
skipping to change at page 16, line 28 skipping to change at page 16, line 37
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 | | Extended Highest Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter | | ECT (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (1) Counter | | ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Counter | not-ECT Counter | | ECN-CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Packet Counter | Duplication Counter | | Loss Packet Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ECN Feedback Report Format Figure 2: ECN Feedback Report Format
The ECN Feedback Report contains the following fields: The ECN Feedback Report contains the following fields:
Extended Highest Sequence Number: The 32-bit Extended highest Extended Highest Sequence Number: The 32-bit Extended highest
sequence number received, as defined by [RFC3550]. Indicates the sequence number received, as defined by [RFC3550]. Indicates the
highest RTP sequence number to which this report relates. highest RTP sequence number to which this report relates.
ECT(0) Counter: The 32-bit cumulative number of RTP packets with ECT(0) Counter: The 32-bit cumulative number of RTP packets with
ECT(0) received from this SSRC. ECT(0) received from this SSRC.
ECT(1) Counter: The 32-bit cumulative number of RTP packets with ECT(1) Counter: The 32-bit cumulative number of RTP packets with
ECT(1) received from this SSRC. ECT(1) received from this SSRC.
CE Counter: The cumulative number of RTP packets received from this ECN-CE Counter: The cumulative number of RTP packets received from
SSRC since the receiver joined the RTP session that were ECN-CE this SSRC since the receiver joined the RTP session that were
marked, including ECN-CE marks in any duplicate packets. The ECN-CE marked, including ECN-CE marks in any duplicate packets.
receiver should keep track of this value using a local The receiver should keep track of this value using a local
representation that is at least 32-bits, and only include the 16- representation that is at least 32-bits, and only include the 16-
bits with least significance. In other words, the field will wrap bits with least significance. In other words, the field will wrap
if more than 65535 packets has been received. if more than 65535 ECN-CE marked packets have been received.
not-ECT 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 not-ECT. The receiver should keep track of ECN field value of not-ECT. The receiver should keep track of
this value using a local representation that is at least 32-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 not-ECT packets have
received. been received.
Lost Packets Counter: The cumulative number of RTP packets that the Lost Packets Counter: The cumulative number of RTP packets that the
receiver expected to receive minus the number of packets it receiver expected to receive minus the number of packets it
actually received that are not a duplicate of an already received actually received that are not a duplicate of an already received
packet, from this SSRC since the receiver joined the RTP session. packet, from this SSRC since the receiver joined the RTP session.
Note that packets that arrive late are not counted as lost. The Note that packets that arrive late are not counted as lost. The
receiver should keep track of this value using a local receiver should keep track of this value using a local
representation that is at least 32-bits, and only include the 16- representation that is at least 32-bits, and only include the 16-
bits with least significance. In other words, the field will wrap bits with least significance. In other words, the field will wrap
if more than 65535 packets have been received. if more than 65535 packets are lost.
Duplication Counter: The cumulative number of RTP packets received Duplication Counter: The cumulative number of RTP packets received
that are a duplicate of an already received packet from this SSRC that are a duplicate of an already received packet from this SSRC
since the receiver joined the RTP session. The receiver should since the receiver joined the RTP session. The receiver should
keep track of this value using a local representation that is at keep track of this value using a local representation that is at
least 32-bits, and only include the 16-bits with least least 32-bits, and only include the 16-bits with least
significance. In other words, the field will wrap if more than significance. In other words, the field will wrap if more than
65535 packets have been received. 65535 duplicate packets have been received.
All fields in the ECN Feedback Report are unsigned integers in All fields in the ECN Feedback Report are unsigned integers in
network byte order. Each ECN Feedback Report corresponds to a single network byte order. Each ECN Feedback Report corresponds to a single
RTP source (SSRC). Multiple sources can be reported by including RTP source (SSRC). Multiple sources can be reported by including
multiple ECN Feedback Reports packets in an compound RTCP packet. multiple ECN Feedback Reports packets in an compound RTCP packet.
The counters SHALL be initiated to 0 for each new SSRC received. The counters SHALL be initiated to 0 for each new SSRC received.
This to enable detection of CE or Packet loss already on the initial This to enable detection of ECN-CE marks or Packet loss on the
report from a specific participant. initial report from a specific participant.
The usage of at least 32-bit counters allows even extremely high The use of at least 32-bit counters allows even extremely high packet
packet volume applications to not have wrapping of counters within volume applications to not have wrapping of counters within any
any timescale close to the reporting intervals. However, 32-bits are timescale close to the RTCP reporting intervals. However, 32-bits
not sufficiently large to disregard the fact that wrappings may are not sufficiently large to disregard the fact that wrappings may
happen during the life time of a long-lived RTP session. Thus happen during the life time of a long-lived RTP session. Thus
handling of wrapping of these counters MUST be supported. It is handling of wrapping of these counters MUST be supported. It is
recommended that implementations uses local representation of these recommended that implementations uses local representation of these
counters that are longer than 32-bits to enable easy handling of counters that are longer than 32-bits to enable easy handling of
wraps. wraps.
There is a difference in packet duplication reports between the There is a difference in packet duplication reports between the
packet loss counter that is defined in the Receiver Report Block packet loss counter that is defined in the Receiver Report Block
[RFC3550] and that defined here. To avoid holding state for what RTP [RFC3550] and that defined here. To avoid holding state for what RTP
sequence numbers have been received, [RFC3550] specifies that one can sequence numbers have been received, [RFC3550] specifies that one can
count packet loss by counting the number of received packets and count packet loss by counting the number of received packets and
comparing it to the number of packets expected. As a result a packet comparing it to the number of packets expected. As a result a packet
duplication can hide a packet loss. However, when populating the ECN duplication can hide a packet loss. However, when populating the ECN
Feedback report, a receiver needs to track the sequence numbers Feedback report, a receiver needs to track the sequence numbers
actually received and count duplicates and packet loss separately to actually received and count duplicates and packet loss separately to
provide a more reliable indication. Reordering may however still provide a more reliable indication. Reordering may however still
result in that packet loss is reported in one report and then removed result in that packet loss is reported in one report and then removed
in the next. in the next.
The CE counter is robust for packet duplication. Adding each The ECN-CE counter is robust for packet duplication. Adding each
received CE marked packet to the counter is not an issue, in fact it received ECN-CE marked packet to the counter is not an issue, in fact
is required to ensure complete tracking of the ECN state. If one of it is required to ensure complete tracking of the ECN state. If one
the clones was CE marked that is still an indication of congestion. of the clones was ECN-CE marked that is still an indication of
Packet duplication has potential impact on the ECN verification and congestion. Packet duplication has potential impact on the ECN
thus there is a need to count the duplicates. verification and 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 Report and is blocks carries the same information as the ECN Feedback Report and is
be based on the same underlying information. However, the ECN be based on the same underlying information. However, the ECN
Feedback Report is intended to report on a CE mark as soon as Feedback Report is intended to report on an ECN-CE mark as soon as
possible, while this extended report is for the regular RTCP possible, while this extended report is for the regular RTCP
reporting and continuous verification of the ECN functionality end- reporting and continuous verification of the ECN functionality end-
to-end. to-end.
The ECN Summary report block consists of one RTCP XR report block 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 header, shown in Figure 3 followed by one or more ECN summary report
data blocks, as defined in Figure 4. 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
skipping to change at page 19, line 14 skipping to change at page 19, line 22
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 (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (1) Counter | | ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Counter | not-ECT Counter | | ECN-CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Packet Counter | Duplication Counter | | Loss Packet Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: RTCP XR ECN Summary Report Figure 4: RTCP XR ECN Summary Report
The RTCP XR ECN Summary Report contains the following fields: 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].
skipping to change at page 19, line 44 skipping to change at page 20, line 7
reports where the block length is not a multiple of five octets, reports where the block length is not a multiple of five octets,
since these cannot be valid. 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.
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. ECN-CE Counter: as in Section 5.1.
not-ECT Counter: as in Section 5.1. not-ECT Counter: as in Section 5.1.
Loss Packet Counter: as in Section 5.1. Loss Packet Counter: as in Section 5.1.
Duplication Counter: as in Section 5.1. Duplication Counter: as in Section 5.1.
The Extended Highest Sequence number counter for each SSRC is not The Extended Highest Sequence number counter for each SSRC is not
present in RTCP XR report, in contrast to the feedback version. The present in RTCP XR report, in contrast to the feedback version. The
reason is that this summary report will rely on the information sent reason is that this summary report will rely on the information sent
skipping to change at page 20, line 43 skipping to change at page 20, line 51
defined to indicate the use of the RTCP XR ECN summary block and the defined to indicate the use of the RTCP XR ECN summary block and the
RTP/AVPF feedback format for ECN. One ICE option SDP representation 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, and MUST NOT be used at the session level. It media level attribute, and MUST NOT be used at the session level. It
is not subject to the character set chosen. The aim of this is not subject to the character set chosen. The aim of this
signalling is to indicate the capability of the sender and receivers signalling is to indicate the capability of the sender and receivers
support of ECN, and to negotiate the method of ECN initiation to be to support ECN, and to negotiate the method of ECN initiation to be
used in the session. The attribute takes a list of initiation used in the session. The attribute takes a list of initiation
methods, ordered in decreasing preference. The defined values for methods, ordered in decreasing preference. The defined values for
the initiation method are: 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.
skipping to change at page 21, line 37 skipping to change at page 21, line 40
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
incoming packets, 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". parameter to "setonly" or both set it to "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.
skipping to change at page 24, line 35 skipping to change at page 24, line 35
included in declarative usage, to indicate the minimal capability is included in declarative usage, to indicate the minimal capability is
required by the consumer of the SDP. So for example in a SSM session required by the consumer of the SDP. So for example in a SSM session
the participants configured with a particular SDP will all be in a the participants configured with a particular SDP will all be in a
media receive only mode, thus mode=readonly will work as the media receive only mode, thus mode=readonly will work as the
capability of reporting on the ECN markings in the received is what capability of reporting on the ECN markings in the received is what
is required. However, using "mode=readonly" also in ASM sessions is is required. However, using "mode=readonly" also in ASM sessions is
reasonable, unless all senders are required to attempt to use ECN for reasonable, unless all senders are required to attempt to use ECN for
their outgoing RTP data traffic, in which case the mode needs to be their outgoing RTP data traffic, in which case the mode needs to be
set to "setread". set to "setread".
6.1.3. General Use of the "a=ecn-capable-rtp:" Attribute
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 RTP/AVPF's (RTP/AVPF) [RFC4585] or other profile that inherits RTP/AVPF's
skipping to change at page 25, line 47 skipping to change at page 25, line 49
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
attribute if it does not wish to use ECN, or doesn't have the attribute if it does not wish to use ECN, or doesn't have the
capability to use ECN. If the ICE initiation method (Section 7.2.2) capability to use ECN. If the ICE initiation method (Section 7.2.2)
actually is going to be used, it is also needs to be explicitly is actually going to be used, it is also needs to be explicitly
negotiated using the "a=ecn-capable-rtp" attribute. This ICE option negotiated using the "a=ecn-capable-rtp" attribute. This ICE option
SHALL be included when the ICE initiation method is offered or SHALL be included when the ICE initiation method is offered or
declared in the SDP. declared in the SDP.
Note: This signalling mechanism is not strictly needed as long as Note: This signalling mechanism is not strictly needed as long as
the STUN ECN testing capability is used within the context of this the STUN ECN testing capability is used within the context of this
document. It may however be useful if the ECN verification document. It may however be useful if the ECN verification
capability is used in additional contexts. capability is used in additional contexts.
7. Use of ECN with RTP/UDP/IP 7. Use of ECN with RTP/UDP/IP
skipping to change at page 26, line 26 skipping to change at page 26, line 27
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. An RTP system that supports ECN and uses SDP capability to use ECN. An RTP system that supports ECN and uses SDP
for its signalling MUST implement the SDP extension to signal ECN for its signalling MUST implement the SDP extension to signal ECN
capability as described in Section 6.1, the RTCP ECN feedback SDP capability as described in Section 6.1, the RTCP ECN feedback SDP
parameter defined in Section 6.2, and the XR Block ECN SDP parameter parameter defined in Section 6.2, and the XR Block ECN SDP parameter
defined in Section 6.3. It MAY also implement alternative ECN defined in 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. Other signalling systems needs to define the in Section 6.4. Other signalling systems will need to define
corresponding signalling parameters to what is defined for SDP. signalling parameters corresponding to those defined for SDP.
The "ecn-capable-rtp" SDP attribute MUST always be used when The "ecn-capable-rtp" SDP attribute MUST be used when employing ECN
employing ECN for RTP according to this specification in systems for RTP according to this specification in systems using SDP. As the
using SDP. As the RTCP XR ECN summary report is required RTCP XR ECN summary report is required independently of the
independently of the initialization method or congestion control initialization method or congestion control scheme, the "rtcp-xr"
scheme, the "rtcp-xr" attribute with the "ecn-sum" parameter MUST attribute with the "ecn-sum" parameter MUST also be used. The
also be used. The "rtcp-fb" attribute with the "nack" parameter "rtcp-fb" attribute with the "nack" parameter "ecn" MUST be used
"ecn" MUST be used whenever the initialization method or a congestion whenever the initialization method or a congestion control algorithm
control algorithm requiring timely sender side knowledge of received requiring timely sender side knowledge of received CE markings. If
CE markings. If the congestion control scheme uses additional the congestion control scheme requires additional signalling, this
signalling they should be indicated as appropriate for those should be indicated as appropriate.
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. All session participants connected over the same transport ECN use. All session participants connected over the same transport
will need to use the same initiation method. RTP mixers or will need to use the same initiation method. RTP mixers or
translators can use different initiation methods to different translators can use different initiation methods to different
participants that are connected over different underlying transports. participants that are connected over different underlying transports.
The mixer or translator will need to do individual signalling with The mixer or translator will need to do individual signalling with
each participant and ensure to be consistent with the ECN support in each participant to ensure it is consistent with the ECN support in
those cases the mixer or translator does not function as one end- those cases where it does not function as one end-point for the ECN
point for the ECN control loop. 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.
skipping to change at page 28, line 17 skipping to change at page 28, line 23
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 Middlebox. 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 a random ECT pattern is intended to be used, at interval. In case a random ECT pattern is intended to be used, at
least one packet with ECT(0) and one with ECT(1) should be sent least one packet with ECT(0) and one with ECT(1) should be sent
per reporting interval, in case a single ECT marking is to be per reporting interval; in case a single ECT marking is to be
used, only that ECT value SHOULD be sent. The RTP sender SHALL used, only that ECT value SHOULD be sent. The RTP sender SHALL
continue to send some ECT marked traffic as long as the ECN continue to send some ECT marked traffic as long as the ECN
initiation phase continues. The sender SHOULD NOT mark all RTP initiation phase continues. The sender SHOULD NOT mark all RTP
packets as ECT 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 use 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 the 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
in an RTP session, the receivers in the session MUST listen for in an RTP session, the receivers in the session MUST listen for
ECT or ECN-CE marked RTP packets, and generate RTCP ECN feedback ECT or ECN-CE marked RTP packets, and generate RTCP ECN feedback
packets (Section 5.1) to mark their receipt. An immediate or packets (Section 5.1) to mark their receipt. An immediate or
early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD
be generated on receipt of the first ECT or ECN-CE marked packet be generated on receipt of the first ECT or ECN-CE marked packet
from a sender that has not previously sent any ECT traffic. Each from a sender that has not previously sent any ECT traffic. Each
regular RTCP report MUST also contain an ECN summary report regular RTCP report MUST also contain an ECN summary report
skipping to change at page 29, line 37 skipping to change at page 29, line 38
report or an RTCP XR ECN summary report indicating successful report or an RTCP XR ECN summary report indicating successful
receipt of the ECT-marked packets, with no negative indications, receipt of the ECT-marked packets, with no negative indications,
from a single RTP receiver (where a single RTP receiver is from a single RTP receiver (where a single RTP receiver is
considered as all SSRCs used by a single RTCP CNAME). After 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 are any other participants in the session. Thus as long as there are any other participants in the session. Thus as long as
any additional SSRC that report on the ECN usage are using the any additional SSRC that report on the ECN usage are using the
same CNAME as the previous reports and they are all indicating same RTCP CNAME as the previous reports and they are all
functional ECN the sender may continue. If other participants are indicating functional ECN the sender may continue. If other
detected, i.e., other CNAMEs, the sender MUST fallback to only participants are detected, i.e., other RTCP CNAMEs, the sender
ECT-marking a small fraction of its RTP packets, while it MUST fallback to only ECT-marking a small fraction of its RTP
determines if ECN can be supported following the full procedure packets, while it determines if ECN can be supported following the
described above. Different CNAMEs received over an unicast full procedure described above. Different RTCP CNAMEs received
transport may occur when using translators in a multi-party RTP over an unicast transport may occur when using translators in a
session (e.g., when using a centralised conference bridge). multi-party RTP session (e.g., when using a centralised conference
bridge).
Note: The above optimization supports peer to peer unicast Note: The above optimization supports peer to peer unicast
transport with several SSRCs multiplexed onto the same flow transport with several SSRCs multiplexed onto the same flow
(e.g., SSRC multiplexed RTP retransmission [RFC4588]). It is (e.g., a single participant with two video cameras, or SSRC
desirable to be able to rapidly negotiate ECN support for such multiplexed RTP retransmission [RFC4588]). It is desirable to
a session, but the optimisation above can fail if there are be able to rapidly negotiate ECN support for such a session,
but the optimisation above can fail if there are
implementations that use the same CNAME for different parts of implementations that use the same CNAME for different parts of
a distributed implementation that have different transport a distributed implementation that have different transport
characteristics (e.g., if a single logical endpoint is split characteristics (e.g., if a single logical endpoint is split
across multiple hosts). across multiple hosts).
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
skipping to change at page 30, line 39 skipping to change at page 30, line 43
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 Note that this method is only applicable to sessions when the remote
destinations are unicast addresses. In addition transport destinations are unicast addresses. In addition, transport
translators that do not terminate the ECN control loop and may translators that do not terminate the ECN control loop and may
distribute received packets to more than one other receiver needs to distribute received packets to more than one other receiver must
either not allow this method (use the RTP/RTCP method instead) or either disallow this method (and use the RTP/RTCP method instead), or
implement additional handling for this case as discussed below. This implement additional handling as discussed below. This is because
is because the ICE initialization method verifies the underlying the ICE initialization method verifies the underlying transport to
transport to one particular address and port. If the receiver at one particular address and port. If the receiver at that address and
that address and port intends to use the received packets in a multi- port intends to use the received packets in a multi-point session
point session then the tested capabilities and the actual session then the tested capabilities and the actual session behavior are not
behavior are not matched. 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 an additional which is nominated for usage. At that point an additional
connectivity check is performed, sending the "ECN Check" attribute in connectivity check is performed, sending the "ECN Check" attribute in
a STUN packet that is ECT marked. On reception of the packet, a STUN a STUN packet that is ECT marked. On reception of the packet, a STUN
server supporting this extension will note the received ECN field server supporting this extension will note the received ECN field
value, and send a STUN/UDP/IP packet in reply with the ECN field set value, and send a STUN/UDP/IP packet in reply with the ECN field set
skipping to change at page 32, line 9 skipping to change at page 32, line 13
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 The ICE based initialization method does require some special
consideration when used by a translator. This is especially for consideration when used by a translator. This is especially for
transport translators and translators that fragments or reassembles transport translators and translators that fragment or reassemble
packets as they do not separate the ECN control loops between the packets, since they do not separate the ECN control loops between the
end-points and the translator. Such a translator that uses ICE based end-points and the translator. Whe using ICE-based initiation, such
initialization needs to ensure that any participants joining an RTP a translator must ensure that any participants joining an RTP session
session for which ECN has been negotiated are successfully verified for which ECN has been negotiated are successfully verified in the
in the direction from the translator to the joining participant or direction from the translator to the joining participant.
correctly handles remarking of ECT RTP packets towards that Alternatively, it must correctly handle remarking of ECT RTP packets
participant. When a new participant joins the session, the towards that participant. When a new participant joins the session,
translator will perform a check towards the new participant. If that the translator will perform a check towards the new participant. If
is successfully completed the ECT properties of the session are that is successfully completed the ECT properties of the session are
maintained for the other senders in the session. If the check fails maintained for the other senders in the session. If the check fails
then the existing senders will now see a participant that fails to then the existing senders will now see a participant that fails to
receive ECT. Thus the failure detection in those senders will receive ECT. Thus the failure detection in those senders will
eventually detect this. However to avoid misusing the network on the eventually detect this. However to avoid misusing the network on the
path from the translator to the new participant, the translator SHALL path from the translator to the new participant, the translator SHALL
remark the traffic intended to be forwarded from ECT to non-ECT. Any 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 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 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 translator fails the ECT check then only that sender will not
contribute any ECT marked traffic towards the translator. contribute any ECT marked traffic towards the translator.
skipping to change at page 33, line 15 skipping to change at page 33, line 19
lack of reception by a receiver SHOULD therefore wait for a second lack of reception by a receiver SHOULD therefore wait for a second
RTCP report from that receiver to be sure that the lack of reception RTCP report from that receiver to be sure that the lack of reception
is due to ECT-marking. Since this recovery process can take several is due to ECT-marking. Since this recovery process can take several
tens of seconds, during which time the RTP session is unusable for tens of seconds, during which time the RTP session is unusable for
media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation
method be used in environments where ECN-blocking middleboxes are method be used in environments where ECN-blocking middleboxes are
likely to be present. likely to be present.
7.3. Ongoing Use of ECN Within an RTP Session 7.3. Ongoing Use of ECN Within an RTP Session
Once ECN usage has been successfully initiated for an RTP sender, Once ECN has been successfully initiated for an RTP sender, that
that sender begins sending all RTP data packets as ECT-marked, and sender begins sending all RTP data packets as ECT-marked, and its
its receivers continue sending ECN feedback information via RTCP receivers send ECN feedback information via RTCP packets. This
packets. This section describes procedures for sending ECT-marked section describes procedures for sending ECT-marked data, providing
data, providing ECN feedback information via RTCP, responding to ECN ECN feedback information via RTCP, responding to ECN feedback
feedback information, and detecting failures and misbehaving information, and detecting failures and misbehaving receivers.
receivers.
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 use, it SHOULD mark all
all the RTP data packets it sends as ECT. The sender SHOULD mark the RTP data packets it sends as ECT. The sender SHOULD mark packets
packets as ECT(0) unless the receiver expresses a preference for as ECT(0) unless the receiver expresses a preference for ECT(1) or
ECT(1) or random using the "ect" parameter in the "a=ecn-capable-rtp" 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 [RFC6189] control packets) that are multiplexed on the same UDP ZRTP [RFC6189] control packets) that are multiplexed on the same UDP
port. For control packets there might be exceptions, like the STUN port. For control packets there might be exceptions, 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 is required. The feedback RTCP packet SHALL consist
if ECN-CE marks or packet drops are detected. The feedback RTCP of at least one ECN feedback packet (Section 5.1) reporting on the
packet sent SHALL consist of at least one ECN feedback packet packets received since the last ECN feedback packet, and will contain
(Section 5.1) reporting on the packets received since the last ECN (at least) an RTCP SR/RR packet and an SDES packet, unless reduced
feedback packet, and will contain an RTCP SR or RR packet unless size RTCP [RFC5506] is used. The RTP/AVPF profile in early or
reduced size RTCP [RFC5506] is used. The RTP/AVPF profile in early immediate feedback mode SHOULD be used where possible, to reduce the
or immediate feedback mode SHOULD be used where possible, to reduce interval before feedback can be sent. To reduce the size of the
the interval before feedback can be sent. To reduce the size of the
feedback message, reduced size RTCP [RFC5506] MAY be used if feedback message, reduced size RTCP [RFC5506] MAY be used if
supported by the end-points. Both RTP/AVPF and reduced size RTCP supported by the end-points. Both RTP/AVPF and reduced size RTCP
MUST be negotiated in the session set-up signalling before they can MUST be negotiated in the session set-up signalling before they can
be used. 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
skipping to change at page 34, line 25 skipping to change at page 34, line 27
considered. The RTP/AVPF transmission rules will limit the amount of considered. The RTP/AVPF transmission rules will limit the amount 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.
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 is a
notification that congestion is being experienced. 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 a congestion provide the congestion control algorithm with a congestion
notification, that triggers the algorithm to react as if packet loss notification that triggers the algorithm to react as if packet loss
had occurred. had occurred. There should be no difference in congestion response
if ECN-CE marks or packet drops are detected.
We note that there MAY be other reactions to ECN-CE specified in the 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 is 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 to it as if packet loss adaptation mechanism so that it can react as if packet loss was
was reported. The congestion control algorithm to be used is not reported. The congestion control algorithm to be used is not
specified here, although TFRC [RFC5348] is one example that might specified here, although TFRC [RFC5348] is one 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
skipping to change at page 35, line 43 skipping to change at page 35, line 50
congestion control algorithm needs to use the signalling to congestion control algorithm needs to use the signalling to
indicate which features of ECN for RTP are required. indicate which features of ECN for RTP are required.
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 problem is diverse paths, i.e., when different receivers don't see
the same path, and thus have different bottlenecks, so the receivers the same path, and thus have different bottlenecks, so the receivers
may get ECN-CE marked packets due to congestion at different points may get ECN-CE marked packets due to congestion at different points
in 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 receivers
settle for the lowest common rate. having to 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.
skipping to change at page 36, line 28 skipping to change at page 36, line 33
benefit over behaving flows (cheating). Th ECN Nonce [RFC3540] is an benefit over behaving flows (cheating). Th ECN Nonce [RFC3540] is an
addition to TCP that attempts to solve this issue as long as the addition to TCP that attempts to solve this issue as long as the
sender acts on behalf of the network. The assumption about the sender acts on behalf of the network. The assumption about the
senders acting on the behalf of the network may be reduced due to the senders acting on the behalf of the network may be reduced due to the
nature of peer-to-peer use of RTP. Still a significant portion of nature of peer-to-peer use of RTP. Still a significant portion of
RTP senders are infrastructure devices (for example, streaming media RTP senders are infrastructure devices (for example, streaming media
servers) that do have an interest in protecting both service quality servers) that do have an interest in protecting both service quality
and the network. Even though there may be cases where nonce can be and the network. Even though there may be cases where nonce can be
applicable also for RTP, it is not included in this specification. applicable also for RTP, it is not included in this specification.
This as a receiver interested in cheating would simple claim to not This as a receiver interested in cheating would simple claim to not
support nonce, or even ECN itself. It is however worth mentioning support nonce, or even ECN itself. It is, however, worth mentioning
that, as real-time media is commonly sensitive to increased delay and that, as real-time media is commonly sensitive to increased delay and
packet loss, it will be in both the media sender and receivers packet loss, it will be in both the media sender and receivers
interest to minimise the number and duration of any congestion events interest to minimise the number and duration of any congestion events
as they will adversely affect media quality. 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 the ECN functionality. The gravest is if the node drops packets with the ECN
field set to ECT(0), ECT(1), or CE. This can be detected by the field set to ECT(0), ECT(1), or ECN-CE. This can be detected by the
receiver when it receives an RTCP SR packet indicating that a sender receiver when it receives an RTCP SR packet indicating that a sender
has sent a number of packets that it has not received. The sender has sent a number of packets that it has not received. The sender
may also detect it based on the receivers RTCP RR packet where the may also detect such a middlebox based on the receiver's RTCP RR
extended sequence number is not advanced due to the failure to packet, when the extended sequence number is not advanced due to the
receive packets. If the packet loss is less than 100% then packet failure to receive packets. If the packet loss is less than 100%,
loss reporting in either the ECN feedback information or RTCP RR will then packet loss reporting in either the ECN feedback information or
indicate the situation. The other action is to re-mark a packet from RTCP RR will indicate the situation. The other action is to re-mark
ECT or CE to not-ECT. That has less dire results, however, it should a packet from ECT or ECN-CE to not-ECT. That has less dire results,
be detected so that ECN usage can be suspended to prevent misusing however it should be detected so that ECN usage can be suspended to
the network. prevent misusing the network.
The RTCP XR ECN summary packet and the ECN feedback packet allow the The RTCP XR ECN summary packet and the ECN feedback packet allow the
sender to compare the number of ECT marked packets of different types sender to compare the number of ECT marked packets of different types
received with the number it actually sent. The number of ECT packets received with the number it actually sent. The number of ECT packets
received plus the number of CE marked and lost packets should received, plus the number of ECN-CE marked and lost packets, should
correspond to the number of sent ECT marked packets plus the number correspond to the number of sent ECT marked packets plus the number
of received duplicates. If these numbers doesn't agree there are two of received duplicates. If these numbers doesn't agree there are two
likely reasons, a translator changing the stream or not carrying the likely reasons, a translator changing the stream or not carrying the
ECN markings forward, or that some node re-marks the packets. In ECN markings forward, or that some node re-marks the packets. In
both cases the usage of ECN is broken on the path. By tracking all both cases the usage of ECN is broken on the path. By tracking all
the different possible ECN field values a sender can quickly detect the different possible ECN field values a sender can quickly detect
if some non-compliant behavior is 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 that includes at least the RTCP RR and the ECN feedback packet that includes at least the RTCP RR and the ECN
feedback message to report this to the sender. This will speed up feedback message to report this to the sender. This will speed up
the detection at the sender of the losses and thus triggering sender the detection of the loss at the sender, thus triggering sender side
side mitigation. 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 are potentially 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
occurs to a path that is ECN capable. occurs to a path that is ECN capable.
2. Renegotiating the session to disable ECN support. This is a 2. Renegotiate the session to disable ECN support. This is a choice
choice that is suitable if the impact of ECT probing on the media that is suitable if the impact of ECT probing on the media
quality are noticeable. If multiple initiations has been quality is noticeable. If multiple initiations have been
successful but the following full usage of ECN has resulted in successful, but the following full usage of ECN has resulted in
the fallback procedures then disabling of the ECN support is the fallback procedures, then disabling of the ECN support is
RECOMMENDED. RECOMMENDED.
We foresee the possibility of flapping ECN capability due to several We foresee the possibility of flapping ECN capability due to several
reasons: video switching MCU or similar middleboxes that selects to reasons: video switching MCU or similar middleboxes that selects to
deliver media from the sender only intermittently; load balancing deliver media from the sender only intermittently; load balancing
devices may in worst case result in that some packets take a devices may in worst case result in that some packets take a
different network path then the others; mobility solutions that different network path then the others; mobility solutions that
switch underlying network path in a transparent way for the sender or switch underlying network path in a transparent way for the sender or
receiver; and membership changes in a multicast group. It is however receiver; and membership changes in a multicast group. It is however
appropriate to mention that there are also issues such as re-routing appropriate to mention that there are also issues such as re-routing
of traffic due to a flappy route table or excessive reordering and of traffic due to a flappy route table or excessive reordering and
other issues that are not directly ECN related but nevertheless may other issues that are not directly ECN related but nevertheless may
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 the ECN summary report
report information in detecting various types of ECN path issues. information can be used to detect various types of ECN path issues.
Lets start to review the information the reports provide on a per We first review the information the RTCP reports provide on a per
source (SSRC) basis: source (SSRC) basis:
CE Counter: The number of RTP packets received so far in the session ECN-CE Counter: The number of RTP packets received so far in the
with an ECN field set to CE. session 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.
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. session with an ECN field set to not-ECT.
Lost Packets counter: The number of RTP packets. that where expected Lost Packets counter: The number of RTP packets that where expected
based on sequence numbers but never received. based on sequence numbers but never received.
Duplication Counter: The number of received RTP packets that are Duplication Counter: The number of received RTP packets that are
duplicates of already received ones. 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 initialised to zero to provide value for the RTP
stream sender from the very first report. After the first report the stream sender from the first report. After the first report, the
changes between the latest received and the previous one is changes between the last received report and the previous report are
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, taking wrapping into account. This definition is also
also robust to packet losses, since if one report is missing, the robust to packet losses, since if one report is missing, the
reporting interval becomes longer, but is otherwise equally valid. reporting interval becomes longer, but is otherwise equally valid.
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 ECN-CE counters should be equal to the
of ECT marked packet sent. Two issues may cause a mismatch in these number of ECT marked packet sent. Two issues may cause a mismatch in
statistics: severe network congestion or unresponsive congestion these statistics: severe network congestion or unresponsive
control might cause some ECT-marked packets to be lost, and packet congestion control might cause some ECT-marked packets to be lost,
duplication might result in some packets being received, and counted and packet duplication might result in some packets being received,
in the statistics, multiple times (potentially with a different ECN- and counted in the statistics, multiple times (potentially with a
mark on each copy of the duplicate). different ECN-mark on each copy of the duplicate).
The rate of duplication is tracked, allowing one to take the The rate of packet duplication is tracked, allowing one to take the
duplication into account. The value of the ECN field for duplicates duplication into account. The value of the ECN field for duplicates
will also be counted and when comparing the figures one needs to take will also be counted and when comparing the figures one needs to take
some fraction of packet duplicates that are non-ECT and some fraction some fraction of packet duplicates that are non-ECT and some fraction
of packet duplicates being ECT into account into the calculation. of packet duplicates being ECT into account into the calculation.
Thus when only sending non-ECT then the number of sent packets plus Thus when only sending non-ECT then the number of sent packets plus
reported duplicates equals the number of received non-ECT. When reported duplicates equals the number of received non-ECT. When
sending only ECT then number of sent ECT packets plus duplicates will 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- equal ECT(0), ECT(1), ECN-CE and packet loss. When sending a mix of
ECT and ECT then there is an uncertainty if any duplicate or packet non-ECT and ECT then there is an uncertainty if any duplicate or
loss was an non-ECT or ECT. If the packet duplication is completely packet loss was an non-ECT or ECT. If the packet duplication is
independent of the usage of ECN, then the fraction of packet completely independent of the usage of ECN, then the fraction of
duplicates should be in relation to the number of non-ECT vs ECT packet duplicates should be in relation to the number of non-ECT vs
packet sent during the period of comparison. This relation does not ECT packet sent during the period of comparison. This relation does
hold for packet loss, where higher rates of packet loss for non-ECT not hold for packet loss, where higher rates of packet loss for non-
is expected than for ECT traffic. More on packet loss below. ECT is expected than for ECT traffic.
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 has
changed towards not-ECT then this is clearly indication that the path substantially changed towards not-ECT, then this is clearly an
results in clearing of the ECT field. indication that the path 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 approximately equal to the loss rate for ECT when counting should be approximately equal to the loss rate for ECT when counting
skipping to change at page 41, line 9 skipping to change at page 41, line 17
packets MUST be ECN marked identically to the original; if several packets MUST be ECN marked identically to the original; if several
ECN marked packets are combined into one, the outgoing packet MUST be 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 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, 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 then it MUST be ECT marked if any of the incoming packets were ECT
marked. marked.
RTCP ECN feedback packets (Section 5.1) contain seven fields that are 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 duplication counter, the the extended highest sequence number, the duplication counter, the
lost packets counter, the CE counter, and not-ECT counter, the ECT(0) lost packets counter, the ECN-CE counter, and not-ECT counter, the
counter, and the ECT(1) counter. The RTCP XR report block for ECN ECT(0) counter, and the ECT(1) counter. The RTCP XR report block for
summary information (Section 5.2) includes all of these fields except ECN summary information (Section 5.2) includes all of these fields
the extended highest sequence number which is present in the report except the extended highest sequence number which is present in the
block in an SR or RR packet. The procedures for rewriting these report block in an SR or RR packet. The procedures for rewriting
fields are the same for both RTCP ECN feedback packet and the XR ECN these fields are the same for both RTCP ECN feedback packet and the
summary packet. RTCP 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 ECN-CE counter, the not-ECT counter, the ECT(0)
counter and the ECT(1) counter minus the duplication counter, from counter and the ECT(1) counter minus the duplication counter, from
the extended highest sequence number. For subsequent RTCP ECN the extended highest sequence number. For subsequent RTCP ECN
feedback packets, the starting sequence number may be determined as feedback packets, the starting sequence number may be determined as
being one after the extended highest sequence number of the previous being one after the extended highest sequence number of the previous
RTCP ECN feedback packet received from the same SSRC. These values RTCP ECN feedback packet received from the same SSRC. These values
are in the sequence number space of the translated packets. are in the sequence number space of the 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
skipping to change at page 46, line 7 skipping to change at page 46, line 14
stun-parameters/stun-parameters.xhtml. stun-parameters/stun-parameters.xhtml.
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 use of ECN with RTP over UDP as specified in this document has
the following known security issues that need 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: An attacker that can modify the
the traffic between the media sender and a receiver can achieve traffic between the media sender and a receiver can achieve either
either of two things: 1) Report a lot of packets as being of two things: 1) Report a lot of packets as being Congestion
Congestion Experience marked, thus forcing the sender into a Experience marked, thus forcing the sender into a congestion
congestion response; or 2) Ensure that the sender disable the response; or 2) Ensure that the sender disable the usage of ECN by
usage of ECN by reporting failures to receive ECN by changing the reporting failures to receive ECN by changing the counter fields.
counter fields. This can also be accomplished by injecting false This can also be accomplished by injecting false RTCP packets to
RTCP packets to the media sender. Reporting a lot of CE marked the media sender. Reporting a lot of ECN-CE marked traffic is
traffic is likely the more efficient denial of service tool as likely the more efficient denial of service tool as that may
that may likely force the application to use lowest possible bit- likely force the application to use lowest possible bit-rates.
rates. The prevention against an external threat is to integrity The prevention against an external threat is to integrity protect
protect the RTCP feedback information and authenticate the sender the RTCP feedback information and authenticate the sender.
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 as sensitive information. If it is considered not considered as sensitive information. If it is considered
sensitive the RTCP feedback should be encrypted. sensitive the RTCP feedback should be encrypted.
Changing the ECN bits: An on-path attacker that sees 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
skipping to change at page 51, line 32 skipping to change at page 51, line 32
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 initialization 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 sends 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 use is also indicated. report, so their use is also indicated.
13. Open Issues 13. Acknowledgments
As this draft is under development some known open issues exist and
are collected here. Please consider them and provide input.
1. The negotiation and directionality attribute is going to need
some consideration for multi-party sessions when readonly
capability might be sufficient to enable ECN for all incoming
streams. However, it would beneficial to know if no potential
sender support setting ECN.
2. Consider initiation optimizations that allows for multi SSRC
sender nodes to still have rapid usage of ECN.
3. Should we report congestion in bytes or packets? RTCP usually
does this in terms of packets, but there may be an argument that
we want to report bytes for ECN.
draft-ietf-tsvwg-byte-pkt-congest is extremely unclear on what is
the right approach.
4. We have a saturation problem with the packet loss counters. They
do need to continue working even if saturation happens due to
long sessions where more lost packets than the counters can
handle.
14. Acknowledgments
The authors wish to thank the following persons for their reviews and The authors wish to thank the following persons for their reviews and
comments: Thomas Belling, Bob Briscoe, Roni Even, Thomas Frankkila, comments: Thomas Belling, Bob Briscoe, Roni Even, Thomas Frankkila,
Christian Groves, Cullen Jennings Tom Van Caenegem, Simo Christian Groves, Cullen Jennings Tom Van Caenegem, Simo
Veikkolainen, Lei Zhu, Christer Holmgren. Veikkolainen, Lei Zhu, and Christer Holmgren.
15. References 14. References
15.1. Normative References 14.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-02 (work in draft-ietf-mmusic-ice-options-registry-02 (work in
progress), May 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.
skipping to change at page 53, line 14 skipping to change at page 52, line 36
April 2010. April 2010.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, September 2008. RFC 5348, September 2008.
[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 14.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.
[RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989. RFC 1112, August 1989.
[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.
 End of changes. 86 change blocks. 
282 lines changed or deleted 260 lines changed or added

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