draft-ietf-avt-ecn-for-rtp-01.txt   draft-ietf-avt-ecn-for-rtp-02.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft I. Johansson Internet-Draft I. Johansson
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: September 9, 2010 C. Perkins Expires: January 11, 2011 C. Perkins
University of Glasgow University of Glasgow
P. O'Hanlon P. O'Hanlon
UCL UCL
K. Carlberg K. Carlberg
G11 G11
March 8, 2010 July 10, 2010
Explicit Congestion Notification (ECN) for RTP over UDP Explicit Congestion Notification (ECN) for RTP over UDP
draft-ietf-avt-ecn-for-rtp-01 draft-ietf-avt-ecn-for-rtp-02
Abstract Abstract
This document specifies how explicit congestion notification (ECN) This document specifies how explicit congestion notification (ECN)
can be used with RTP/UDP flows that use RTCP as feedback mechanism. can be used with RTP/UDP flows that use RTCP as feedback mechanism.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 11, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4
3. Discussion, Requirements, and Design Rationale . . . . . . . . 4 3. Discussion, Requirements, and Design Rationale . . . . . . . . 4
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
4. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 9 4. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 9
4.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 12 4.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 12
4.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 17 4.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 17
4.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 22 4.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 22
4.4. Detecting Failures and Receiver Misbehaviour . . . . . . . 26 4.4. Detecting Failures and Receiver Misbehaviour . . . . . . . 26
5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 29 5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 29
5.1. ECN Feedback packet . . . . . . . . . . . . . . . . . . . 29 5.1. ECN Feedback packet . . . . . . . . . . . . . . . . . . . 29
5.2. RTCP XR Report block for ECN summary information . . . . . 32 5.2. RTCP XR Report block for ECN summary information . . . . . 32
5.3. RTCP XR Report Block for ECN Nonce . . . . . . . . . . . . 33 5.3. RTCP XR Report Block for ECN Nonce . . . . . . . . . . . . 33
6. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 36 6. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 36
6.1. Fragmentation and Reassembly in Translators . . . . . . . 36 6.1. Fragmentation and Reassembly in Translators . . . . . . . 36
6.2. Generating RTCP ECN Feedback in Translators . . . . . . . 37 6.2. Generating RTCP ECN Feedback in Media Transcoders . . . . 38
6.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 37 6.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 39
7. Implementation considerations . . . . . . . . . . . . . . . . 37 7. Implementation considerations . . . . . . . . . . . . . . . . 40
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
8.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 38 8.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 40
8.2. AVPF Transport Feedback Message . . . . . . . . . . . . . 38 8.2. AVPF Transport Feedback Message . . . . . . . . . . . . . 40
8.3. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 38 8.3. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 40
8.4. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 38 8.4. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 41
8.5. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 38 8.5. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 41
9. Security Considerations . . . . . . . . . . . . . . . . . . . 38 9. Security Considerations . . . . . . . . . . . . . . . . . . . 41
10. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 41 10. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 43
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 41 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 44
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
12.1. Normative References . . . . . . . . . . . . . . . . . . . 42 12.1. Normative References . . . . . . . . . . . . . . . . . . . 44
12.2. Informative References . . . . . . . . . . . . . . . . . . 42 12.2. Informative References . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46
1. Introduction 1. Introduction
This document outlines how Explicit Congestion Notification (ECN) This document outlines how Explicit Congestion Notification (ECN)
[RFC3168] can be used for RTP [RFC3550] flows running over UDP/IP [RFC3168] can be used for RTP [RFC3550] flows running over UDP/IP
which use RTCP as feedback mechanism. The solution consists of which use RTCP as a feedback mechanism. The solution consists of
feedback of ECN congestion experienced markings to sender using RTCP, feedback of ECN congestion experienced markings to the sender using
verification of ECN functionality end-to-end, and how to initiate ECN RTCP, verification of ECN functionality end-to-end, and how to
usage. The initiation process will have some dependencies on the initiate ECN usage. The initiation process will have some
signalling mechanism used to establish the RTP session, a dependencies on the signalling mechanism used to establish the RTP
specification for mechanisms using SDP is included. session, a specification for signalling mechanisms using SDP is
included.
ECN is getting attention as a method to minimise the impact of ECN is getting attention as a method to minimise the impact of
congestion on real-time multimedia traffic. When ECN is used, the congestion on real-time multimedia traffic. When ECN is used, the
network can signal to applications that congestion is occurring, network can signal to applications that congestion is occurring,
whether that congestion is due to queuing at a congested link, whether that congestion is due to queuing at a congested link,
limited resources and coverage on a radio link, or other reasons. limited resources and coverage on a radio link, or other reasons.
This congestion signal allows applications to reduce their This congestion signal allows applications to react in a controlled
transmission rate in a controlled manner, rather than responding to manner, rather than responding to uncontrolled packet loss, and so
uncontrolled packet loss, and so improves the user experience while improves the user experience while benefiting the network. By
benefiting the network. default, this reaction can be expected to be in the form of reducing
the transmission rate. In addition, the use of ECN support outlined
in this document helps minimize the disruption of the flow (and the
user experience) by rapidly conveying congested conditions without
packet loss.
The introduction of ECN into the Internet requires changes to both The introduction of ECN into the Internet requires changes to both
the network and transport layers. At the network layer, IP the network and transport layers. At the network layer, IP
forwarding has to be updated to allow routers to mark packets, rather forwarding has to be updated to allow routers to mark packets, rather
than discarding them in times of congestion [RFC3168]. In addition, than discarding them in times of congestion [RFC3168]. In addition,
transport protocols have to be modified to inform the sender that ECN transport protocols have to be modified to inform the sender that ECN
marked packets are being received, so it can respond to the marked packets are being received, so it can respond to the
congestion. TCP [RFC3168], SCTP [RFC4960] and DCCP [RFC4340] have congestion. TCP [RFC3168], SCTP [RFC4960] and DCCP [RFC4340] have
been updated to support ECN, but to date there is no specification been updated to support ECN, but to date there is no specification
how UDP-based transports, such as RTP [RFC3550], can use ECN. This how UDP-based transports, such as RTP [RFC3550], can use ECN. This
is due to the lack of feedback mechanism directly in UDP. Instead is due to the lack of feedback mechanisms directly in UDP. Instead
the protocol on top of UDP needs to provide that feedback, which for the signaling control protocol on top of UDP needs to provide that
RTP is RTCP. feedback, which for RTP is RTCP.
The remainder of this memo is structured as follows. We start by The remainder of this memo is structured as follows. We start by
describing the conventions, definitions and acronyms used in this describing the conventions, definitions and acronyms used in this
memo in Section 2, and the design rationale and applicability in memo in Section 2, and the design rationale and applicability in
Section 3. The means by which ECN is used with RTP over UDP is Section 3. The means by which ECN is used with RTP over UDP is
defined in Section 4, along with RTCP extensions for ECN feedback in defined in Section 4, along with RTCP extensions for ECN feedback in
Section 5. In Section 6 we discuss how RTCP ECN feedback is handled Section 5. In Section 6 we discuss how RTCP ECN feedback is handled
in RTP translators and mixers. Section 7 discusses some in RTP translators and mixers. Section 7 discusses some
implementation considerations, Section 8 lists IANA considerations, implementation considerations, Section 8 lists IANA considerations,
and Section 9 discusses the security considerations. and Section 9 discusses the security considerations.
skipping to change at page 5, line 19 skipping to change at page 5, line 19
other transport protocols. other transport protocols.
Middleboxes: The RTP framework explicitly supports the concept of Middleboxes: The RTP framework explicitly supports the concept of
mixers and translators, which are middleboxes that are involved in mixers and translators, which are middleboxes that are involved in
media transport functions. media transport functions.
Multicast: RTP is explicitly a group communication protocol, and was Multicast: RTP is explicitly a group communication protocol, and was
designed from the start to support IP multicast (primarily ASM, designed from the start to support IP multicast (primarily ASM,
although a recent extension supports SSM with unicast feedback). although a recent extension supports SSM with unicast feedback).
Application Awareness: ECN support via TCP, DCCP, and SCTP constrain
the awareness and reaction to packet loss within those protocols.
By adding support of ECN through RTCP, the application is made
aware of packet loss and may choose one or more approaches in
response to that loss.
These differences will significantly alter the shape of ECN support These differences will significantly alter the shape of ECN support
in RTP-over-UDP compared to ECN support in TCP, SCTP, and DCCP, but in RTP-over-UDP compared to ECN support in TCP, SCTP, and DCCP, but
do not invalidate the need for ECN support. Indeed, in many ways, do not invalidate the need for ECN support. Indeed, in many ways,
ECN support is more important for RTP sessions, since the impact of ECN support is more important for RTP sessions, since the impact of
packet loss in real-time audio-visual media flows is highly visible packet loss in real-time audio-visual media flows is highly visible
to users. Effective ECN support for RTP flows running over UDP will to users. Effective ECN support for RTP flows running over UDP will
allow real-time audio-visual applications to respond to the onset of allow real-time audio-visual applications to respond to the onset of
congestion before routers are forced to drop packets, allowing those congestion before routers are forced to drop packets, allowing those
applications to control how they reduce their transmission rate, and applications to control how they reduce their transmission rate, and
hence media quality, rather than responding to, and trying to conceal hence media quality, rather than responding to, and trying to conceal
the effects of, unpredictable packet loss. Furthermore, widespread the effects of, unpredictable packet loss. Furthermore, widespread
deployment for ECN and active queue management in routers, should it deployment for ECN and active queue management in routers, should it
occur, can potentially reduce unnecessary queueing delays in routers, occur, can potentially reduce unnecessary queueing delays in routers,
lowering the round-trip time and benefiting interactive applications lowering the round-trip time and benefiting interactive applications
of RTP, such a voice telephony. of RTP, such as voice telephony.
3.1. Requirements 3.1. Requirements
Considering ECN and these protocols one can create a set of Considering ECN and these protocols one can create a set of
requirements that must be satisfied to at least some degree if ECN is requirements that must be satisfied to at least some degree if ECN is
used by an other protocol (such as RTP over UDP) used by an other protocol (such as RTP over UDP)
o REQ 1: A mechanism to negotiate and initiate the usage of ECN for o REQ 1: A mechanism MUST negotiate and initiate the usage of ECN
RTP/UDP/IP sessions is required for RTP/UDP/IP sessions
o REQ 2: A mechanism to feedback the reception of any packets that
are ECN-CE marked to the packet sender is required
o REQ 3: Provide mechanism to minimise the possibility for cheating o REQ 2: A mechanism MUST feedback the reception of any packets that
is desirable are ECN-CE marked to the packet sender
o REQ 3: Provide mechanism SHOULD minimise the possibility for
cheating
o REQ 4: Some detection and fallback mechanism is needed to avoid o REQ 4: Some detection and fallback mechanism SHOULD exist to avoid
loss of communication due to the attempted usage of ECN in case an loss of communication due to the attempted usage of ECN in case an
intermediate node clears ECT or drops packets that are ECT marked. intermediate node clears ECT or drops packets that are ECT marked.
o REQ 5: Negotiation of ECN should not significantly increase the o REQ 5: Negotiation of ECN SHOULD NOT significantly increase the
time taken to negotiate and set-up the RTP session (an extra RTT time taken to negotiate and set-up the RTP session (an extra RTT
before the media can flow is unlikely to be acceptable for some before the media can flow is unlikely to be acceptable for some
use cases). use cases).
o REQ 6: Negotiation of ECN should not cause media clipping at the o REQ 6: Negotiation of ECN SHOULD NOT cause media clipping at the
start of a session. start of a session.
The following sections describes how these requirements can be meet The following sections describes how these requirements can be meet
for RTP over UDP. for RTP over UDP.
3.2. Applicability 3.2. Applicability
The use of ECN with RTP over UDP is dependent on negotiation of ECN The use of ECN with RTP over UDP is dependent on negotiation of ECN
capability between the sender and receiver(s), and validation of ECN capability between the sender and receiver(s), and validation of ECN
support in all elements of the network path(s) traversed. RTP is support in all elements of the network path(s) traversed. RTP is
used in a heterogeneous range of network environments and topologies, used in a heterogeneous range of network environments and topologies,
with various different signalling protocols, all of which need to be with various different signalling protocols, all of which need to be
verified to support ECN before it can be used. verified to support ECN before it can be used.
The usage of ECN is further dependent on a capability of the RTP The usage of ECN is further dependent on a capability of the RTP
media flow to react to congestion signalled by ECN marked packets. media 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 at the sender by changing the media encoding, at adaptation can occur various forms and at various nodes. As an
the receiver by changing the subscription to a layered encoding, or example, the sender can change the media encoding, or the receiver
in a transcoding middlebox. RFC 5117 identifies seven topologies in can change the subscription to a layered encoding, or either reaction
which RTP sessions may be configured, and which may affect the can be accomplished by a transcoding middlebox. RFC 5117 identifies
ability to use ECN: seven topologies in which RTP sessions may be configured, and which
may affect the ability to use ECN:
Topo-Point-to-Point: This is a standard unicast flow. ECN may be Topo-Point-to-Point: This is a standard unicast flow. ECN may be
used with RTP in this topology in an analogous manner to its use used with RTP in this topology in an analogous manner to its use
with other unicast transport protocols, with RTCP conveying ECN with other unicast transport protocols, with RTCP conveying ECN
feedback messages. feedback messages.
Topo-Multicast: This is either an any source multicast (ASM) group Topo-Multicast: This is either an any source multicast (ASM) group
with potentially several active senders and multicast RTCP with potentially several active senders and multicast RTCP
feedback, or a source specific multicast (SSM) group with a single feedback, or a source specific multicast (SSM) group with a single
sender and unicast RTCP feedback from receivers. RTCP is designed sender and unicast RTCP feedback from receivers. RTCP is designed
skipping to change at page 7, line 7 skipping to change at page 7, line 15
network paths to those receivers, support ECN (see Section 4.2). network paths to those receivers, support ECN (see Section 4.2).
It is somewhat more difficult to determine if all network paths It is somewhat more difficult to determine if all network paths
from all senders to all receivers support ECN. Accordingly, we from all senders to all receivers support ECN. Accordingly, we
allow ECN to be used by an RTP sender using multicast UDP provided allow ECN to be used by an RTP sender using multicast UDP provided
the sender has verified that the paths to all its known receivers the sender has verified that the paths to all its known receivers
support ECN, and irrespective of whether the paths from other support ECN, and irrespective of whether the paths from other
senders to their receivers support ECN. Note that group senders to their receivers support ECN. Note that group
membership may change during the lifetime of a multicast RTP 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. Senders must use the mechanisms described in Section 4.4 capable. Senders must use the mechanisms described in Section 4.4
to monitor that all receivers continue to support ECN, and needs to monitor that all receivers continue to support ECN, and they
to fallback to non-ECN use if they do not. need to fallback to non-ECN use if any senders do not.
Topo-Translator: An RTP translator is an RTP-level middlebox that is Topo-Translator: An RTP translator is an RTP-level middlebox that is
invisible to the other participants in the RTP session (although invisible to the other participants in the RTP session (although
it is usually visible in the associated signalling session). it is usually visible in the associated signalling session).
There are two types of RTP translator: those do not modify the There are two types of RTP translator: those do not modify the
media stream, and are concerned with transport parameters, for media stream, and are concerned with transport parameters, for
example a multicast to unicast gateway; and those that do modify example a multicast to unicast gateway; and those that do modify
the media stream, for example transcoding between different media the media stream, for example transcoding between different media
codecs. A single RTP session traverses the translator, and the codecs. A single RTP session traverses the translator, and the
translator must rewrite RTCP messages passing through it to match translator must rewrite RTCP messages passing through it to match
the changes it makes to the RTP data packets. A legacy, ECN- the changes it makes to the RTP data packets. A legacy, ECN-
unaware, RTP translator is expected to ignore the ECN bits on unaware, RTP translator is expected to ignore the ECN bits on
received packets, and to set the ECN bits to not-ECT when sending received packets, and to set the ECN bits to not-ECT when sending
packets, so causing ECN negotiation on the path containing the packets, so causing ECN negotiation on the path containing the
translator to fail (any new RTP translator that does not wish to translator to fail (any new RTP translator that does not wish to
support ECN may do similarly). An ECN aware RTP translator may support ECN may do so similarly). An ECN aware RTP translator may
act in one of three ways: act in one of three ways:
* If the translator does not modify the media stream, it should * If the translator does not modify the media stream, it should
copy the ECN bits unchanged from the incoming to the outgoing copy the ECN bits unchanged from the incoming to the outgoing
datagrams, unless it is overloaded and experiencing congestion, datagrams, unless it is overloaded and experiencing congestion,
in which case it may mark the outgoing datagrams with an ECN-CE in which case it may mark the outgoing datagrams with an ECN-CE
mark. Such a translator passes RTCP feedback unchanged. mark. Such a translator passes RTCP feedback unchanged.
* If the translator modifies the media stream to combine or split * If the translator modifies the media stream to combine or split
RTP packets, but does not otherwise transcode the media, it RTP packets, but does not otherwise transcode the media, it
skipping to change at page 9, line 24 skipping to change at page 9, line 32
layered coding to support more heterogeneous paths. layered coding to support more heterogeneous paths.
To ensure timely feedback of CE marked packets, this mechanism To ensure timely feedback of CE marked packets, this mechanism
requires support for the RTP/AVPF profile [RFC4585] or any of its requires support for the RTP/AVPF profile [RFC4585] or any of its
derivatives, such as RTP/SAVPF [RFC5124]. The standard RTP/AVP derivatives, such as RTP/SAVPF [RFC5124]. The standard RTP/AVP
profile [RFC3551] does not allow any early or immediate transmission profile [RFC3551] does not allow any early or immediate transmission
of RTCP feedback, and has a minimal RTCP interval whose default value of RTCP feedback, and has a minimal RTCP interval whose default value
(5 seconds) is many times the normal RTT between sender and receiver. (5 seconds) is many times the normal RTT between sender and receiver.
The control of which RTP data packets are marked as ECT, and whether The control of which RTP data packets are marked as ECT, and whether
ECT(0) or ECT(1) is used, is due to the sender. RTCP packets must ECT(0) or ECT(1) is used, is due to the sender. RTCP packets MUST
not be ECT marked, whether generated by sender or receivers. NOT be ECT marked, whether generated by sender or receivers.
4. Use of ECN with RTP/UDP/IP 4. 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 10, line 39 skipping to change at page 10, line 46
request was received (see Section 8.4), along with an ICE request was received (see Section 8.4), along with an ICE
signalling option (Section 8.5). signalling option (Section 8.5).
o Thirdly, the sender may make a leap of faith that ECN will work. o Thirdly, the sender may make a leap of faith that ECN will work.
This is only recommended for applications that know they are This is only recommended for applications that know they are
running in controlled environments where ECN functionality has running in controlled environments where ECN functionality has
been verified through other means. In this mode it is assumed been verified through other means. In this mode it is assumed
that ECN works, and the system reacts to failure indicators if the that ECN works, and the system reacts to failure indicators if the
assumption proved wrong. The use of this method relies on a high assumption proved wrong. The use of this method relies on a high
confidence that ECN operation will be successful, or an confidence that ECN operation will be successful, or an
application where failure are not serious. The impact on the application where failure is not serious. The impact on the
network and other users must be considered when making a leap of network and other users must be considered when making a leap of
faith, so there are limitations on when this method is allowed. faith, so there are limitations on when this method is allowed.
The first mechanism, using RTP with RTCP feedback, has the advantage The first mechanism, using RTP with RTCP feedback, has the advantage
of working for all RTP sessions, but the disadvantages of potential of working for all RTP sessions, but the disadvantages of potential
clipping if ECN marked RTP packets are discarded by middleboxes, and clipping if ECN marked RTP packets are discarded by middleboxes, and
slow verification of ECN support. The STUN-based mechanism is faster slow verification of ECN support. The STUN-based mechanism is faster
to verify ECN support, but only works in those scenarios supported by to verify ECN support, but only works in those scenarios supported by
end-to-end STUN, such as within an ICE exchange. The third one, end-to-end STUN, such as within an ICE exchange. The third one,
leap-of-faith, has the advantage of avoiding additional tests or leap-of-faith, has the advantage of avoiding additional tests or
complexities and enabling ECN usage from the first media packet. The complexities and enabling ECN usage from the first media packet. The
downside is that if the end-to-end path contains middleboxes that do downside is that if the end-to-end path contains middleboxes that do
not pass ECN, the impact on the application can be severe: in the not pass ECN, the impact on the application can be severe: in the
worst case, all media could be lost if a middlebox that discards ECN worst case, all media could be lost if a middlebox that discards ECN
marked packets is present. A less severe effect, but still requiring marked packets is present. A less severe effect, but still requiring
reaction, is the presence of a middlebox that remarks ECT marked reaction, is the presence of a middlebox that re-marks ECT marked
packets to non-ECT, possibly marking packets with a CE mark as non- packets to non-ECT, possibly marking packets with a CE mark as non-
ECT. This can force the network into heavy congestion due to non- ECT. This can force the network into heavy congestion due to non-
responsiveness, and seriously impact media quality. responsiveness, and seriously impact media quality.
Once ECN support has been verified (or assumed) to work for all Once ECN support has been verified (or assumed) to work for all
receivers, a sender marks all its RTP packets as ECT packets, while receivers, a sender marks all its RTP packets as ECT packets, while
receivers rapidly feedback any CE marks to the sender using RTCP in receivers rapidly feedback any CE marks to the sender using RTCP in
RTP/AVPF immediate or early feedback mode. An RTCP feedback report RTP/AVPF immediate or early feedback mode. An RTCP feedback report
is sent as soon as possible by the transmission rules for feedback is sent as soon as possible by the transmission rules for feedback
that are in place. This feedback report indicates new CE marks since that are in place. This feedback report indicates the receipt of new
last ECN feedback packet and also the number of new CE marks through CE marks since the last ECN feedback packet, and also counts the
a accumulative sum. This is the mechanism to provide the fastest total number of CE marked packets through a cumulative sum. This is
possible feedback to senders about CE marks. On receipt of a CE the mechanism to provide the fastest possible feedback to senders
marked packet, the system must react to congestion as-if packet loss about CE marks. On receipt of a CE marked packet, the system must
has been reported. Section Section 4.3 describes the ongoing use of react to congestion as-if packet loss has been reported. Section 4.3
ECN with an RTP session. describes the ongoing use of ECN with an RTP session.
This rapid feedback is not optimised for reliability, therefore an This rapid feedback is not optimised for reliability, therefore an
additional procedure is used to ensure more reliable, but less additional procedure, the RTCP ECN summary reports, is used to ensure
timely, reporting of the ECN information. An ECN summary report more reliable, but less timely, reporting of the ECN information.
should also be sent in regular RTCP reports. The ECN summary report The ECN summary report contains the same information as the ECN
contains the same information as the ECN feedback format, only packed feedback format, only packed differently for better efficiency with
differently for better efficiency with large reports. By using large reports. It is sent in a compound RTCP packet, along with
accumulative counters for seen CE, ECT, not-ECT or packet loss the regular RTCP reception reports. By using cumulative counters for
sender can determine what events has happened since the last report, seen CE, ECT, not-ECT and packet loss the sender can determine what
independently of any RTCP packets having been lost. events have happened since the last report, independently of any RTCP
packets having been lost.
RTCP traffic must not be ECT marked for the following reason. ECT RTCP traffic MUST NOT be ECT marked for the following reason. ECT
marked traffic may be dropped if the path is not ECN compliant. As marked traffic may be dropped if the path is not ECN compliant. As
RTCP is used to provide feedback about what has been transmitted and RTCP is used to provide feedback about what has been transmitted and
what ECN markings that are received it is important that these are what ECN markings that are received, it is important that these are
received in cases when ECT marked traffic is not getting through. received in cases when 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 packet being sent through a node that is ECN non-compliant, thus re-
remarking or dropping packets with ECT set. To prevent this from marking or dropping packets with ECT set. To prevent this from
impacting the application for longer than necessary, the operation of impacting the application for longer than necessary, the operation of
ECN is constantly monitored by all senders. Both the RTCP ECN ECN is constantly monitored by all senders. Both the RTCP ECN
summary reports and the ECN feedback packets allow the sender to summary reports and the ECN feedback packets allow the sender to
compare the number of ECT(0), ECT(1), and non-ECT marked packets with compare the number of ECT(0), ECT(1), and non-ECT marked packets
those that were sent, while also reporting CE marked and lost received with the number that were sent, while also reporting CE
packets. If these numbers do not agree with what was sent, it can be marked and lost packets. If these numbers do not agree, it can be
inferred that the path does not reliably pass ECN-marked packets inferred that the path does not reliably pass ECN-marked packets
(Section 4.4.2 discusses how to interpret the different cases). A (Section 4.4.2 discusses how to interpret the different cases). A
sender detecting a possible ECN non-compliance issue should then stop sender detecting a possible ECN non-compliance issue should then stop
sending ECT marked packets to determine if that allows the packets to sending ECT marked packets to determine if that allows the packets to
be correctly delivered. If the issues can be connected to ECN, then be correctly delivered. If the issues can be connected to ECN, then
ECN usage is suspended and possibly also re-negotiated. ECN usage is suspended and possibly also re-negotiated.
This specification offers an option of computing and reporting an ECN This specification offers an option of computing and reporting an ECN
nonce over all received packets that where not ECN-CE marked or nonce over all received packets that were not ECN-CE marked or
reported explicitly lost. This provides an additional means to reported explicitly lost. This provides an additional means to
detect any packet remarking that happens in the network, and can also detect any packet re-marking that happens in the network, and can
be used by a sender to detect receivers that lie about reception of also be used by a sender to detect receivers that lie about reception
CE-marked packets (it is to be noted that the incentive for receivers of CE-marked packets (it is to be noted that the incentive for
to lie in their ECN reports is low for RTP/UDP/IP sessions, since receivers to lie in their ECN reports is low for RTP/UDP/IP sessions,
increased congestion levels are likely to cause unpredictable packet since increased congestion levels are likely to cause unpredictable
losses that decrease the media quality more than would reducing the packet losses that decrease the media quality more than would
data rate). To enable the sender to verify the ECN nonce, the sender reducing the data rate). To enable the sender to verify the ECN
must learn the sequence number of all packets that was either CE nonce, the sender must learn the sequence number of all packets that
marked or lost, otherwise it can't correctly exclude these packet was either CE marked or lost, otherwise it can't correctly exclude
from the ECN nonce sum. This is done using a new RTCP XR report these packet from the ECN nonce sum. This is done using a new RTCP
type, the Nonce Report, that contains the nonce sums and indicating XR report type, the Nonce Report, that contains the nonce sums and
the lost or ECN-CE marked packets using a run length encoded bit- indicating the lost or ECN-CE marked packets using a run length
vector. Due to the size of ECN Nonce Reports, and as most RTP-based encoded bit-vector (see Section 5.3). Due to the size of ECN Nonce
applications have little incentive to lie about ECN marks, the use of Reports, and as most RTP-based applications have little incentive to
the ECN nonce is OPTIONAL. lie about ECN marks, the use of the ECN nonce is OPTIONAL.
In the detailed specification of the behaviour below, the different In the detailed specification of the behaviour below, the different
functions in the general case will first be discussed. In case functions in the general case will first be discussed. In case
special considerations are needed for middleboxes, multicast usage special considerations are needed for middleboxes, multicast usage
etc, those will be specially discussed in related subsections. etc, those will be specially discussed in related subsections.
4.1. Negotiation of ECN Capability 4.1. Negotiation of ECN Capability
The first stage of ECN negotiation for RTP-over-UDP is to signal the The first stage of ECN negotiation for RTP-over-UDP is to signal the
capability to use ECN. This includes negotiating if ECN is to be capability to use ECN. This includes negotiating if ECN is to be
skipping to change at page 13, line 11 skipping to change at page 13, line 19
Section 4.1.1. It MAY also implement alternative ECN capability Section 4.1.1. It MAY also implement alternative ECN capability
negotiation schemes, such as the ICE extension described in negotiation schemes, such as the ICE extension described in
Section 4.1.2. Section 4.1.2.
4.1.1. Signalling ECN Capability using SDP 4.1.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, which MUST NOT be used at the session level. media level attribute, which MUST NOT be used at the session level.
It is not subject to the character set chosen. The aim of this It 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
to support ECN, and to negotiate the method for ECN initiation to be to support ECN, and to negotiate the method of ECN initiation to be
used in the session. Thus the attribute take a list of methods for used in the session. The attribute takes a list of initiation
initiation, which are ordered in decreasing preference. The defined methods, ordered in decreasing preference. The defined values for
values for the initiation method are: the initiation method are:
rtp: Using RTP and RTCP as defined in Section 4.2.1. rtp: Using RTP and RTCP as defined in Section 4.2.1.
ice: Using STUN within ICE as defined in Section 4.2.2. ice: Using STUN within ICE as defined in Section 4.2.2.
leap: Using the leap of faith method as defined in Section 4.2.3. leap: Using the leap of faith method as defined in Section 4.2.3.
In addition, a number of OPTIONAL parameters may be included in the In addition, a number of OPTIONAL parameters may be included in the
"a=ecn-capable-rtp" attribute as follows: "a=ecn-capable-rtp" attribute as follows:
skipping to change at page 16, line 8 skipping to change at page 16, line 18
nonce. nonce.
The "ect=" parameter in the "a=ecn-capable-rtp" attribute is set The "ect=" parameter in the "a=ecn-capable-rtp" attribute is set
independently in the offer and the answer. Its value in the offer independently in the offer and the answer. Its value in the offer
indicates a preference for the behaviour of the answering party, and indicates a preference for the behaviour of the answering party, and
its value in the answer indicates a preference for the behaviour of its value in the answer indicates a preference for the behaviour of
the offering party. It will be the senders choice if to honor the the offering party. It will be the senders choice if to honor the
receivers preference or not. receivers preference or not.
When SDP is used in a declarative manner, for example in a multicast When SDP is used in a declarative manner, for example in a multicast
session using SAP, negotiation of session description parameters is session using the Session Announcement Protocol (SAP, [RFC2974]),
not possible. The "a=ecn-capable-rtp" attribute MAY be added to the negotiation of session description parameters is not possible. The
session description to indicate that the sender will use ECN in the "a=ecn-capable-rtp" attribute MAY be added to the session description
RTP session. The attribute MUST include a single method of to indicate that the sender will use ECN in the RTP session. The
initiation. Participants MUST NOT join such a session unless they attribute MUST include a single method of initiation. Participants
have the capability to understand ECN-marked UDP packets, implement MUST NOT join such a session unless they have the capability to
the method of initiation, and can generate RTCP ECN feedback (note understand ECN-marked UDP packets, implement the method of
that having the capability to use ECN doesn't necessarily imply that initiation, and can generate RTCP ECN feedback (note that having the
the underlying network path between sender and receiver supports capability to use ECN doesn't necessarily imply that the underlying
ECN). If the nonce parameter is included then the ECN nonce SHALL be network path between sender and receiver supports ECN). If the nonce
used in the session. The mode parameter MAY be included also in parameter is included then the ECN nonce SHALL be used in the
declarative usage, to indicate which capability is required by the session. The mode parameter MAY be included also in declarative
consumer of the SDP. So for example in a SSM session the usage, to indicate which capability is required by the consumer of
participants configured with a particular SDP will all be in a media the SDP. So for example in a SSM session the participants configured
receive only mode, thus mode=readonly will work as the capability of with a particular SDP will all be in a media receive only mode, thus
reporting on the ECN markings in the received is what is required. mode=readonly will work as the capability of reporting on the ECN
markings in the received is what is required.
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 4.3.3, RTP sessions using ECN require rapid As described in Section 4.3.3, RTP sessions using ECN require rapid
RTCP ECN feedback, in order that the sender can react to ECN-CE RTCP ECN feedback, in order that the sender can react to ECN-CE
marked packets. Thus, the use of the Extended RTP Profile for RTCP- marked packets. Thus, the use of the Extended RTP Profile for RTCP-
Based Feedback (RTP/AVPF) [RFC4585] MUST be signalled. Based Feedback (RTP/AVPF) [RFC4585] MUST be signalled.
When using ECN nonce, the RTCP XR signalling indicating the ECN Nonce When using ECN nonce, the RTCP XR signalling indicating the ECN Nonce
report MUST also be included in the SDP [RFC3611]. report MUST also be included in the SDP [RFC3611].
4.1.2. ICE Parameter to Signal ECN Capability 4.1.2. ICE Parameter to Signal ECN Capability
One new ICE [I-D.ietf-mmusic-ice] option, "rtp+ecn", is defined. One new ICE [RFC5245] option, "rtp+ecn", is defined. This is used
This is used with the SDP session level "a=ice-options" attribute in with the SDP session level "a=ice-options" attribute in an SDP offer
an SDP offer to indicate that the initiator of the ICE exchange has to indicate that the initiator of the ICE exchange has the capability
the capability to support ECN for RTP-over-UDP flows (via "a=ice- to support ECN for RTP-over-UDP flows (via "a=ice-options: rtp+ecn").
options: rtp+ecn"). The answering party includes this same attribute The answering party includes this same attribute at the session level
at the session level in the SDP answer if it also has the capability, in the SDP answer if it also has the capability, and removes the
and removes the attribute if it does not wish to use ECN, or doesn't attribute if it does not wish to use ECN, or doesn't have the
have the capability to use ECN. If this initiation method capability to use ECN. If this initiation method (Section 4.2.2)
(Section 4.2.2) actually is going to be used, it is explicitly actually is going to be used, it is explicitly negotiated using the
negotiated using the "a=ecn-capable-rtp" attribute. "a=ecn-capable-rtp" attribute.
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.
4.2. Initiation of ECN Use in an RTP Session 4.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
skipping to change at page 19, line 15 skipping to change at page 19, line 21
Determination of ECN Support: RTP is a group communication protocol, Determination of ECN Support: RTP is a group communication protocol,
where members can join and leave the group at any time. This where members can join and leave the group at any time. This
complicates the ECN initiation phase, since the sender must wait complicates the ECN initiation phase, since the sender must wait
until it believes the group membership has stabilised before it until it believes the group membership has stabilised before it
can determine if the paths to all receivers support ECN (group can determine if the paths to all receivers support ECN (group
membership changes after the ECN initiation phase has completed membership changes after the ECN initiation phase has completed
are discussed in Section 4.3). are discussed in Section 4.3).
An RTP sender shall consider the group membership to be stable An RTP sender shall consider the group membership to be stable
after it has been in the session and sending ECT-marked probe after it has been in the session and sending ECT-marked probe
packets for at least three RTCP reporting intervals (i.e. after packets for at least three RTCP reporting intervals (i.e., after
sending its third regularly scheduled RTCP packet), and when a sending its third regularly scheduled RTCP packet), and when a
complete RTCP reporting interval has passed without changes to the complete RTCP reporting interval has passed without changes to the
group membership. ECN initiation is considered successful when group membership. ECN initiation is considered successful when
the group membership is stable, and all known participants have the group membership is stable, and all known participants have
sent one or more RTCP ECN feedback packets indicating correct sent one or more RTCP ECN feedback packets indicating correct
receipt of the ECT-marked RTP packets generated by the sender. receipt of the ECT-marked RTP packets generated by the sender.
As an optimisation, if an RTP sender is initiating ECN usage As an optimisation, if an RTP sender is initiating ECN usage
towards a unicast address, then it MAY treat the ECN initiation as towards a unicast address, then it MAY treat the ECN initiation as
provisionally successful if it receives a single RTCP ECN feedback provisionally successful if it receives a single RTCP ECN feedback
skipping to change at page 19, line 40 skipping to change at page 19, line 46
monitor the RTCP reports for a period of three RTCP reporting monitor the RTCP reports for a period of three RTCP reporting
intervals from the time the ECN initiation started, to check if intervals from the time the ECN initiation started, to check if
there is any other participants in the session. If other there is any other participants in the session. If other
participants are detected, the sender MUST fallback to only ECT- participants are detected, the sender MUST fallback to only ECT-
marking a small fraction of its RTP packets, while it determines marking a small fraction of its RTP packets, while it determines
if ECN can be supported following the full procedure described if ECN can be supported following the full procedure described
above. above.
Note: One use case that requires further consideration is a Note: One use case that requires further consideration is a
unicast connection with several SSRCs multiplexed onto the same unicast connection with several SSRCs multiplexed onto the same
flow (e.g. SVC video using SSRC multiplexing for the layers). flow (e.g., an SVC video using SSRC multiplexing for the
It is desirable to be able to rapidly negotiate ECN support for layers). It is desirable to be able to rapidly negotiate ECN
such a session, but the optimisation above fails since the support for such a session, but the optimisation above fails
multiple SSRCs make it appear that this is a group since the multiple SSRCs make it appear that this is a group
communication scenario. It's not sufficient to check that all communication scenario. It's not sufficient to check that all
SSRCs map to a common RTCP CNAME to check if they're actually SSRCs map to a common RTCP CNAME to check if they're actually
located on the same device, because there are implementations located on the same device, because there are implementations
that use the same CNAME for different parts of a distributed that use the same CNAME for different parts of a distributed
implementation. implementation.
ECN initiation is considered to have failed at the instant when ECN initiation is considered to have failed at the instant when
any RTP session participant sends an RTCP packet that doesn't any RTP session participant sends an RTCP packet that doesn't
contain an RTCP ECN feedback report or ECN summary report, but has contain an RTCP ECN feedback report or ECN summary report, but has
an RTCP RR with an extended RTP sequence number field that an RTCP RR with an extended RTP sequence number field that
indicates that it should have received multiple (>3) ECT marked indicates that it should have received multiple (>3) ECT marked
RTP packets. This can be due to failure to support the ECN RTP packets. This can be due to failure to support the ECN
feedback format by the receiver or some middlebox, or the loss of feedback format by the receiver or some middlebox, or the loss of
all ECT marked packets. Both indicate a lack of ECN support. all ECT marked packets. Both indicate a lack of ECN support.
If the ECN negotiation succeeds, this indicates that the path can If the ECN negotiation succeeds, this indicates that the path can
pass some ECN-marked traffic, and that the receivers support ECN pass some ECN-marked traffic, and that the receivers support ECN
feedback. This does not necessarily imply that the path can robustly feedback. This does not necessarily imply that the path can robustly
convey ECN feedback; Section Section 4.3 describes the ongoing convey ECN feedback; Section 4.3 describes the ongoing monitoring
monitoring that must be performed to ensure the path continues to that must be performed to ensure the path continues to robustly
robustly support ECN. support ECN.
4.2.2. Detection of ECT using STUN with ICE 4.2.2. Detection of ECT using STUN with ICE
This section describes an OPTIONAL method that can be used to avoid This section describes an OPTIONAL method that can be used to avoid
media impact and also ensure an ECN capable path prior to media media impact and also ensure an ECN capable path prior to media
transmission. This method is considered in the context where the transmission. This method is considered in the context where the
session participants are using ICE [I-D.ietf-mmusic-ice] to find session participants are using ICE [RFC5245] to find working
working connectivity. We need to use ICE rather than STUN only, as connectivity. We need to use ICE rather than STUN only, as the
the verification needs to happen from the media sender to the address verification needs to happen from the media sender to the address and
and port on which the receiver is listening. port on which the receiver is listening.
To minimise the impact of set-up delay, and to prioritise the fact To minimise the impact of set-up delay, and to prioritise the fact
that one has a working connectivity rather than necessarily finding that one has a working connectivity rather than necessarily finding
the best ECN capable network path, this procedure is applied after the best ECN capable network path, this procedure is applied after
having performed a successful connectivity check for a candidate, having performed a successful connectivity check for a candidate,
which is nominated for usage. At that point, and provided the chosen which is nominated for usage. At that point, and provided the chosen
candidate is not a relayed address, one performs an additional candidate is not a relayed address, an additional connectivity check
connectivity check including the here defined STUN attribute "ECT is performed, sending the "ECT Check" attribute in a STUN packet that
Check" and in an UDP/IP packet that are ECT marked. The STUN server is ECT marked. On reception of the packet, the STUN server will note
will upon reception of the packet note the received ECN field value the received ECN field value, and send a STUN/UDP/IP packet in reply,
and in its response send an STUN/UDP/IP Packet with ECN field set to with the ECN field set to not-ECT, and including an ECN check
not-ECT and also include the ECN check STUN attribute. attribute.
The STUN ECN check STUN attribute contains one field and a flag. The The STUN ECN check attribute contains one field and a flag. The flag
flag indicates if the echo field contains a valid value or not. The indicates if the echo field contains a valid value or not. The field
field is the ECN echo field, and when valid contains the two ECN bits is the ECN echo field, and when valid contains the two ECN bits from
from the packet it echoes back. The ECN check STUN attribute is a the packet it echoes back. The ECN check attribute is a
comprehension optional attribute. comprehension optional attribute.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |ECF|V| | Reserved |ECF|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: ECN Check Stun Attribute Figure 1: ECN Check STUN Attribute
V: Valid (1 bit) ECN Echo value field is valid when set to 1, and V: Valid (1 bit) ECN Echo value field is valid when set to 1, and
invalid when set 0. invalid when set 0.
ECF: ECN Echo value field (2 bits) contains the ECN filed value of ECF: ECN Echo value field (2 bits) contains the ECN field value of
the STUN packet it echoes back when field is valid. If invalid the STUN packet it echoes back when field is valid. If invalid
the content is arbitrary. the content is arbitrary.
Reserved: Reserved bits (29 bits) SHOULD be set to 0 on Reserved: Reserved bits (29 bits) SHOULD be set to 0 on
transmission, and SHALL be ignored on reception. transmission, and SHALL be ignored on reception.
This attribute MAY be included in any STUN request to request the ECN This attribute MAY be included in any STUN request to request the ECN
field to be echoed back. In STUN requests the V bit SHALL be set to field to be echoed back. In STUN requests the V bit SHALL be set to
0. A STUN server receiving a request with the ECN Check attribute 0. A STUN server receiving a request with the ECN Check attribute
which understand it SHALL read the ECN field value of the IP/UDP which understand it SHALL read the ECN field value of the IP/UDP
skipping to change at page 21, line 44 skipping to change at page 21, line 44
This method for initiating ECN usage is a leap of faith that assumes This method for initiating ECN usage is a leap of faith that assumes
that ECN will work on the used path(s). It is not generally that ECN will work on the used path(s). It is not generally
recommended as the impact on both the application and the network may recommended as the impact on both the application and the network may
be substantial if the path is not ECN capable. Applications may be substantial if the path is not ECN capable. Applications may
experience high packet loss rates, this is both from dropped ECT experience high packet loss rates, this is both from dropped ECT
marked packets, and as a result of driving the network into higher marked packets, and as a result of driving the network into higher
degrees of congestion by not being responsive to ECN marks. The degrees of congestion by not being responsive to ECN marks. The
network may experience higher degrees of congestion due to the network may experience higher degrees of congestion due to the
unresponsiveness of the sender due to lost ECN-CE marks from non- unresponsiveness of the sender due to lost ECN-CE marks from non-
compliant remarking. compliant re-marking.
The method is to go directly to "ongoing use of ECN" as defined in The method is to go directly to "ongoing use of ECN" as defined in
Section 4.3. Thus all RTP packets MAY be marked as ECT and the Section 4.3. Thus all RTP packets MAY be marked as ECT and the
failure detection MUST be used to detect any case when the assumption failure detection MUST be used to detect any case when the assumption
that the path was ECT capable is wrong. that the path was ECT capable is wrong.
If the sender marks all packets as ECT while transmitting on a path If the sender marks all packets as ECT while transmitting on a path
that contains a middlebox that drops all ECT-marked packets, then a that contains a middlebox that drops all ECT-marked packets, then a
receiver downstream of that middlebox will not receive any RTP data receiver downstream of that middlebox will not receive any RTP data
packets from that sender, and hence will not consider it to be an packets from that sender, and hence will not consider it to be an
skipping to change at page 23, line 15 skipping to change at page 23, line 15
The sender SHALL NOT include ECT marks on outgoing RTCP packets, and The sender SHALL NOT include ECT marks on outgoing RTCP packets, and
SHOULD NOT include ECT marks on any other outgoing control messages SHOULD NOT include ECT marks on any other outgoing control messages
(e.g. STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or (e.g. STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or
ZRTP [I-D.zimmermann-avt-zrtp] control packets) that are multiplexed ZRTP [I-D.zimmermann-avt-zrtp] control packets) that are multiplexed
on the same UDP port. on the same UDP port.
4.3.2. Reporting ECN Feedback via RTCP 4.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 to report this back to the feedback packet as soon as possible (subject to the constraints of
sender. The feedback RTCP packet sent SHALL consist of at least one [RFC4585] and [RFC3550]) to report this back to the sender. The
ECN feedback packet (Section 5) reporting on the packets received feedback RTCP packet sent SHALL consist of at least one ECN feedback
since the last ECN feedback packet, and SHOULD contain an RTCP SR or packet (Section 5) reporting on the packets received since the last
RR packet. The RTP/AVPF profile in early or immediate feedback mode ECN feedback packet, and SHOULD contain an RTCP SR or RR packet. The
SHOULD be used where possible, to reduce the interval before feedback RTP/AVPF profile in early or immediate feedback mode SHOULD be used
can be sent. To reduce the size of the feedback message, reduced where possible, to reduce the interval before feedback can be sent.
size RTCP [RFC5506] MAY be used if supported by the end-points. Both To reduce the size of the feedback message, reduced size RTCP
RTP/AVPF and reduced size RTCP MUST be negotiated in the session [RFC5506] MAY be used if supported by the end-points. Both RTP/AVPF
set-up signalling before they can be used. ECN Nonce information and reduced size RTCP MUST be negotiated in the session set-up
SHOULD NOT be included in early or immediate reports, only when signalling before they can be used. ECN Nonce information SHOULD NOT
regular reports are sent. be included in early or immediate reports, only when regular reports
are sent.
Every time a regular compound RTCP packet is to be transmitted, the Every time a regular compound RTCP packet is to be transmitted, an
RTP receiver MUST include an RTCP XR ECN summary report Section 5.2 ECN-capable RTP receiver MUST include an RTCP XR ECN summary report
as part of the compound packet. If ECN-nonce is enabled the receiver as described in Section 5.2 as part of the compound packet. If ECN-
MUST also include an RTCP XR Nonce report packet Section 5.3. It is nonce is enabled the receiver MUST also include an RTCP XR Nonce
important to configure the RTCP bandwidth (e.g. using an SDP "b=" report packet as described in Section 5.3. It is important to
line) such that the bit-rate is sufficient for a usage that includes configure the RTCP bandwidth (e.g. using an SDP "b=" line) such that
these regular summary and nonce reports, and feedback on ECN-CE the bit-rate is sufficient for a usage that includes these regular
events. summary and nonce reports, and feedback on ECN-CE events.
The multicast feedback implosion problem, that occurs when many The multicast feedback implosion problem, that occurs when many
receivers simultaneously send feedback to a single sender, must also receivers simultaneously send feedback to a single sender, must also
be considered. The RTP/AVPF transmission rules will limit the amount be considered. The RTP/AVPF transmission rules will limit the amount
of feedback that can be sent, avoiding the implosion problem but also of 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.
An open issue is whether we should employ some form of feedback A possible future optimisation might be to define some form of
suppression on ECN-CE feedback for groups? If one can make an feedback suppression mechanism to reduce the RTCP reporting
assumption that a sender will react on a few ECN-CE marks then overhead for group communication using ECN.
suppression could be employed successfully and reduce the RTCP
bandwidth usage.
In case a receiver driven congestion control algorithm is to be used In case a receiver driven congestion control algorithm is to be used
and has been agreed upon through signalling, the algorithm MAY and has been agreed upon through signalling, the algorithm MAY
specify that the immediate scheduling (and later transmission) of specify that the immediate scheduling (and later transmission) of
ECN-CE feedback of any received ECN-CE mark is not required and shall ECN-CE feedback of any received ECN-CE mark is not required and shall
not be done (since it is not necessary for congestion control not be done (since it is not necessary for congestion control
purposes in such cases). In that case ECN feedback is only sent purposes in such cases). In that case ECN feedback is only sent
using regular RTCP reports for verification purpose and in response using regular RTCP reports for verification purpose and in response
to the initiation process ("rtp") of any new media senders as to the initiation process ("rtp") of any new media senders as
specified in Section 4.2.1. specified in Section 4.2.1.
skipping to change at page 24, line 28 skipping to change at page 24, line 26
and the sequence numbers for packets where the ECN marking has been and the sequence numbers for packets where the ECN marking has been
lost to be reported. This information is variable size as it depends lost to be reported. This information is variable size as it depends
on both the total number of packet sent per reporting interval and on both the total number of packet sent per reporting interval and
the CE and Packet loss pattern how many bits are required for the CE and Packet loss pattern how many bits are required for
reporting. reporting.
The RTCP packets may be lost, and to avoid the possibility for The RTCP packets may be lost, and to avoid the possibility for
cheating by "losing" the Nonce information for where one is cheating cheating by "losing" the Nonce information for where one is cheating
the nonce coverage needs to be basically complete. Thus the Nonce the nonce coverage needs to be basically complete. Thus the Nonce
reporting SHOULD cover at least the 3 regular reporting intervals. reporting SHOULD cover at least the 3 regular reporting intervals.
The only exception allowed is if the reporting information becomes to The only exception allowed is if the reporting information becomes
heavy and makes the RTCP report packet become larger than the MTU. too heavy and makes the RTCP report packet become larger than the
In that case a receiver MAY reduce the coverage for the ECN nonce to MTU. In that case a receiver MAY reduce the coverage for the ECN
only the last or two last reporting intervals. A sender should nonce to only the last or two last reporting intervals. A sender
consider the received size report for cases where the coverage is not should consider the received size report for cases where the coverage
at least three reporting intervals and determine if this may be done is not at least three reporting intervals and determine if this may
to cheat or not. Failure to have reported on all intervals MAY be be done to cheat or not. Failure to have reported on all intervals
punished by reducing the congestion safe rate. MAY be punished by reducing the congestion safe rate.
The ECN nonce information in the ECN feedback packet consists of both The ECN nonce information in the ECN feedback packet consists of both
a start value for the nonce prior to the first packet in the a start value for the nonce prior to the first packet in the
reporting interval and the final 2-bit XOR sum over all the received reporting interval and the final 2-bit XOR sum over all the received
ECN values, both not-ECT and ECT for the report interval. The report ECN values, both not-ECT and ECT for the report interval. The report
interval is explicitly signalled in the RTCP XR Nonce report packet. interval is explicitly signalled in the RTCP XR Nonce report packet.
The initial value for the Nonce is 00b. The initial value for the Nonce is 00b.
4.3.3. Response to Congestion Notifications 4.3.3. Response to Congestion Notifications
skipping to change at page 26, line 5 skipping to change at page 25, line 52
control, since when receivers are heterogeneous in regards to control, since when receivers are heterogeneous in regards to
capacity the sender is limited to transmitting at the rate the capacity the sender is limited to transmitting at the rate the
slowest receiver can support. This often becomes a significant slowest receiver can support. This often becomes a significant
limitation as group size grows. Also, as group size increases the limitation as group size grows. Also, as group size increases the
frequency of reports from each receiver decreases, which further frequency of reports from each receiver decreases, which further
reduces the responsiveness of the mechanism. Receiver-driven reduces the responsiveness of the mechanism. Receiver-driven
congestion control has the advantage that each receiver can choose congestion control has the advantage that each receiver can choose
the appropriate rate for its network path, rather than all having to the appropriate rate for its network path, rather than all having to
settle for the lowest common rate. settle for the lowest common rate.
Note: There are many additional references that may be cited here.
If this document is accepted as an AVT work item, some discussion
of the appropriate amount of detail to include here would be
worthwhile.
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 change 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.
4.4. Detecting Failures and Receiver Misbehaviour 4.4. Detecting Failures and Receiver Misbehaviour
ECN-nonce is defined in RFC3540 as a means to ensure that a TCP ECN-nonce is defined in RFC3540 as a means to ensure that a TCP
clients does not mask ECN-CE marks, this assumes that the sending clients does not mask ECN-CE marks, this assumes that the sending
endpoint (server) acts on behalf of the network. endpoint (server) acts on behalf of the network.
The assumption about the senders acting on the behalf of the network The assumption about the senders acting on the behalf of the network
may be reduced due to the nature of peer-to-peer use of RTP. Still a may be reduced due to the nature of peer-to-peer use of RTP. Still a
significant portion of RTP senders are infrastructure devices (for significant portion of RTP senders are infrastructure devices (for
example, streaming media servers) that do have an interest in example, streaming media servers) that do have an interest in
protecting both service quality and the network. In addition as protecting both service quality and the network. In addition, as
real-time media is commonly sensitive to increased delay and packet real-time media is commonly sensitive to increased delay and packet
loss it will be in both media sender and receivers interest to loss, it will be in both media sender and receivers interest to
minimise the number and duration of any congestion events as they minimise the number and duration of any congestion events as they
will affect media quality. will affect media quality.
RTP sessions can also suffer from path changes resulting in a non-ECN RTP sessions can also suffer from path changes resulting in a non-ECN
compliant node becoming part of the path. That node may perform compliant node becoming part of the path. That node may perform
either of two actions that has effect on the ECN and application either of two actions that has effect on the ECN and application
functionality. The gravest is if the node drops packets with any ECN functionality. The gravest is if the node drops packets with any ECN
field values other than 00b. This can be detected by the receiver field values other than 00b. This can be detected by the receiver
when it receives a RTCP SR packet indicating that a sender has sent a when it receives a RTCP SR packet indicating that a sender has sent a
number of packets has not been received. The sender may also detect number of packets has not been received. The sender may also detect
it based on the receivers RTCP RR packet where the extended sequence it based on the receivers RTCP RR packet where the extended sequence
number is not advanced due to the failure to receive packets. If the number is not advanced due to the failure to receive packets. If the
packet loss is less than 100% then packet loss reporting in either packet loss is less than 100% then packet loss reporting in either
the ECN feedback information or RTCP RR will indicate the situation. the ECN feedback information or RTCP RR will indicate the situation.
The other action is to remark a packet from ECT to not-ECT. That has The other action is to re-mark a packet from ECT to not-ECT. That
less dire results, however, it should be detected so that ECN usage has less dire results, however, it should be detected so that ECN
can be suspended to prevent misusing the network. usage can be suspended to prevent misusing the network.
The ECN feedback packet allows the sender to compare the number of The ECN feedback packet allows the sender to compare the number of
ECT marked packets of different type with the number it actually ECT marked packets of different type with the number it actually
sent. The number of ECT packets received plus the number of CE sent. The number of ECT packets received plus the number of CE
marked and lost packets should correspond to the number of sent ECT marked and lost packets should correspond to the number of sent ECT
marked packets. If this number doesn't agree there are two likely marked packets. If this number doesn't agree there are two likely
reasons, a translator changing the stream or not carrying the ECN reasons, a translator changing the stream or not carrying the ECN
markings forward, or that some node remarks the packets. In both markings forward, or that some node re-marks the packets. In both
cases the usage of ECN is broken on the path. By tracking all the cases the usage of ECN is broken on the path. By tracking all the
different possible ECN field values a sender can quickly detect if different possible ECN field values a sender can quickly detect if
some non-compliant behavior is happing on the path. 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.
4.4.1. Fallback mechanisms 4.4.1. Fallback mechanisms
skipping to change at page 27, line 48 skipping to change at page 27, line 42
2. Renegotiating the session to disable ECN support. This is a 2. Renegotiating the session to disable ECN support. This is a
choice that is suitable if the impact of ECT probing on the media choice that is suitable if the impact of ECT probing on the media
quality are noticeable. If multiple initiations has been quality are noticeable. If multiple initiations has 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
switches underlying network path in a transparent way for the sender switches underlying network path in a transparent way for the sender
or receiver; and membership changes in a multicast group. or receiver; and membership changes in a multicast group.
4.4.2. Interpretation of ECN Summary information 4.4.2. Interpretation of ECN Summary information
This section contains discussion on how you can use the ECN summary This section contains discussion on how you can use the ECN summary
report information in detecting various types of ECN path issues. report information in detecting various types of ECN path issues.
Lets start to review the information the reports provide on a per Lets start to review the information the reports provide on a per
source (SSRC) basis: source (SSRC) basis:
CE Counter: The number of RTP packets received so far in the session CE Counter: The number of RTP packets received so far in the session
with an ECN field set to CE (11b). with an ECN field set to CE (11b).
ECT (0/1) Counters: The number of RTP packets received so far in the ECT (0/1) Counters: The number of RTP packets received so far in the
session with an ECN field set to ECT (0) and ECT (1) respectively session with an ECN field set to ECT (0) and ECT (1) respectively
(10b / 01b). (10b / 01b).
skipping to change at page 28, line 51 skipping to change at page 28, line 46
of ECT marked packet sent. Two issues may cause a mismatch in these of ECT marked packet sent. Two issues may cause a mismatch in these
statistics: severe network congestion or unresponsive congestion statistics: severe network congestion or unresponsive congestion
control might cause some ECT-marked packets to be lost, and packet control might cause some ECT-marked packets to be lost, and packet
duplication might result in some packets being received, and counted duplication might result in some packets being received, and counted
in the statistics, multiple times (potentially with a different ECN- in the statistics, multiple times (potentially with a different ECN-
mark on each copy of the duplicate). mark on each copy of the duplicate).
The level of packet duplication included in the report can be The level of packet duplication included in the report can be
estimated from the sum over all of fields counting received packets estimated from the sum over all of fields counting received packets
compared to the number of packets sent. A high level of packet compared to the number of packets sent. A high level of packet
duplication increases the uncertainty in the statistics, making if duplication increases the uncertainty in the statistics, making it
more difficult to draw firm conclusions about the behaviour of the more difficult to draw firm conclusions about the behaviour of the
network. This issue is also present with standard RTCP reception network. This issue is also present with standard RTCP reception
reports. reports.
Detecting clearing of ECN field: If the ratio between ECT and not-ECT Detecting clearing of ECN field: If the ratio between ECT and not-ECT
transmitted in the reports has become all not-ECT or substantially transmitted in the reports has become all not-ECT or substantially
changed towards not-ECT then this is clearly indication that the path changed towards not-ECT then this is clearly indication that the path
results in clearing of the ECT field. results in clearing of the ECT field.
Dropping of ECT packets: To determine if the packet drop ratio is Dropping of ECT packets: To determine if the packet drop ratio is
skipping to change at page 29, line 34 skipping to change at page 29, line 28
behavior. We note that it appears counter-productive for a receiver behavior. We note that it appears counter-productive for a receiver
to attempt to cheat as it most likely will have negative impact on to attempt to cheat as it most likely will have negative impact on
its media quality. However, certain usages of RTP may result in a its media quality. However, certain usages of RTP may result in a
situation that is more similar to TCP, i.e. where packet losses are situation that is more similar to TCP, i.e. where packet losses are
repaired and a higher bit-rate is desirable. Thus RTP sessions that repaired and a higher bit-rate is desirable. Thus RTP sessions that
use repair mechanisms as FEC or retransmission may consider the usage use repair mechanisms as FEC or retransmission may consider the usage
of the ECN nonce to prevent cheating. of the ECN nonce to prevent cheating.
5. RTCP Extensions for ECN feedback 5. RTCP Extensions for ECN feedback
This documents defines three different RTCP extensions: one AVPF NACK This documents defines three different RTCP extensions: one RTCP AVPF
Transport feedback format for urgent ECN information; one RTCP XR ECN NACK Transport feedback format for urgent ECN information; one RTCP
summary report block type for regular reporting of the ECN marking XR ECN summary report block type for regular reporting of the ECN
information; and one additional RTCP XR report block type for ECN marking information; and one additional RTCP XR report block type for
nonce. ECN nonce.
5.1. ECN Feedback packet 5.1. ECN Feedback packet
This AVPF NACK feedback format is intended for usage in AVPF early or This AVPF NACK feedback format is intended for usage in AVPF early or
immediate feedback modes when information needs to urgently reach the immediate feedback modes when information needs to urgently reach the
sender. Thus its main use is to report on reception of an ECN-CE sender. Thus its main use is to report on reception of an ECN-CE
marked RTP packet so that the sender may perform congestion control, marked RTP packet so that the sender may perform congestion control,
or to speed up the initiation procedures by rapidly reporting that or to speed up the initiation procedures by rapidly reporting that
the path can support ECN-marked traffic. The feedback format is also the path can support ECN-marked traffic. The feedback format is also
defined with reduced size RTCP [RFC5506] in mind, where RTCP feedback defined with reduced size RTCP [RFC5506] in mind, where RTCP feedback
packets may be sent without accompanying Sender or Receiver Reports packets may be sent without accompanying Sender or Receiver Reports
that would contain the Extended Highest Sequence number and the that would contain the Extended Highest Sequence number and the
accumulated number of packet losses. Both are important for the ECN accumulated number of packet losses. Both are important for ECN to
functionality to verify functionality and keep track of when CE verify functionality and keep track of when CE marking does occur.
marking does occur.
The RTCP AVPF NACK packet starts with the common header defined by The RTCP AVPF NACK packet starts with the common header defined by
the RTP/AVPF profile [RFC4585] which is reproduced here for the the RTP/AVPF profile [RFC4585] which is reproduced here for the
reader's information: reader's information:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length | |V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source | | SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) : : Feedback Control Information (FCI) :
skipping to change at page 36, line 34 skipping to change at page 36, line 26
6. Processing RTCP ECN Feedback in RTP Translators and Mixers 6. Processing RTCP ECN Feedback in RTP Translators and Mixers
RTP translators and mixers that support ECN feedback are required to RTP translators and mixers that support ECN feedback are required to
process, and potentially modify or generate, RTCP packets for the process, and potentially modify or generate, RTCP packets for the
translated and/or mixed streams. translated and/or mixed streams.
6.1. Fragmentation and Reassembly in Translators 6.1. Fragmentation and Reassembly in Translators
An RTP translator may fragment or reassemble RTP data packets without An RTP translator may fragment or reassemble RTP data packets without
changing the media encoding. An example of this might be to combine changing the media encoding, and without reference to the congestion
packets of a voice-over-IP stream coded with one 20ms frame per RTP state of the networks it bridges. An example of this might be to
packet into new RTP packets with two 20ms frames per packet, thereby combine packets of a voice-over-IP stream coded with one 20ms frame
reducing the header overheads and so stream bandwidth, at the expense per RTP packet into new RTP packets with two 20ms frames per packet,
of an increase in latency. If multiple data packets are re-encoded thereby reducing the header overheads and so stream bandwidth, at the
into one, or vice versa, the RTP translator MUST assign new sequence expense of an increase in latency. If multiple data packets are re-
numbers to the outgoing packets. Losses in the incoming RTP packet encoded into one, or vice versa, the RTP translator MUST assign new
stream may induce corresponding gaps in the outgoing RTP sequence sequence numbers to the outgoing packets. Losses in the incoming RTP
numbers. An RTP translator MUST also rewrite RTCP packets to make packet stream may also induce corresponding gaps in the outgoing RTP
the corresponding changes to their sequence numbers. This section sequence numbers. An RTP translator MUST rewrite RTCP packets to
make the corresponding changes to their sequence numbers, and to
reflect the impact of the fragmentation or reassembly. This section
describes how that rewriting is to be done for RTCP ECN feedback describes how that rewriting is to be done for RTCP ECN feedback
packets. Section 7.2 of [RFC3550] describes general procedures for packets. Section 7.2 of [RFC3550] describes general procedures for
other RTCP packet types. other RTCP packet types.
(tbd: complete this section) RTCP ECN feedback packets (Section 5.1) contain six fields that are
rewritten in an RTP translator that fragments or reassembles packets:
the extended highest sequence number, the lost packets counter, the
CE counter, and not-ECT counter, the ECT(0) counter, and the ECT(1)
counter. The RTCP XR report block for ECN summary information
(Section 5.2) includes a subset of these fields excluding the
extended highest sequence number and lost packets counter. The
procedures for rewriting these fields are the same for both types of
RTCP ECN feedback packet.
6.2. Generating RTCP ECN Feedback in Translators When receiving an RTCP ECN feedback packet, an RTP translator first
determines the range of packets to which the report corresponds. The
extended highest sequence number in the RTCP ECN feedback packet (or
in the RTCP SR/RR packet contained within the compound packet, in the
case of RTCP XR ECN summary reports) specifies the end sequence
number of the range. For the first RTCP ECN feedback packet
received, the initial extended sequence number of the range may be
determined by subtracting the sum of the lost packets counter, the CE
counter, the not-ECT counter, the ECT(0) counter and the ECT(1)
counter from the extended highest sequence number (this will be
inaccurate if there is packet duplication). For subsequent RTCP ECN
feedback packets, the starting sequence number may be determined as
being one after the extended highest sequence number of the previous
RTCP ECN feedback packet received from the same SSRC. These values
are in the sequence number space of the translated packets.
Based on its knowledge of the translation process, the translator
determines the sequence number range for the corresponding original,
pre-translation, packets. The extended highest sequence number in
the RTCP ECN feedback packet is rewritten to match the final sequence
number in the pre-translation sequence number range.
The translator then determines the ratio, R, of the number of packets
in the translated sequence number space (numTrans) to the number of
packets in the pre-translation sequence number space (numOrig) such
that R = numTrans / numOrig. The counter values in the RTCP ECN
feedback report are then scaled by dividing each of them by R. For
example, if the translation process combines two RTP packets into
one, then numOrig will be twice numTrans, giving R=0.5, and the
counters in the translated RTCP ECN feedback packet will be twice
those in the original.
The ratio, R, may have a value that leads to non-integer multiples of
the counters when translating the RTCP packet. For example, a VoIP
translator that combines two adjacent RTP packets into one if they
contain active speech data, but passes comfort noise packets
unchanged, would have an R values of between 0.5 and 1.0 depending on
the amount of active speech. Since the counter values in the
translated RTCP report are integer values, rounding will be necessary
in this case.
When rounding counter values in the translated RTCP packet, the
translator should try to ensure that they sum to the number of RTP
packets in the pre-translation sequence number space (numOrig). The
translator should also try to ensure that no non-zero counter is
rounded to a zero value, since that will lose information that a
particular type of event has occurred. It is recognised that it may
be impossible to satisfy both of these constraints; in such cases, it
is better to ensure that no non-zero counter is mapped to a zero
value, since this preserves congestion adaptation and helps the RTCP-
based ECN initiation process.
It should be noted that scaling the RTCP counter values in this way
is meaningful only on the assumption that the level of congestion in
the network is related to the number of packets being sent. This is
likely to be a reasonable assumption in the type of environment where
RTP translators that fragment or reassemble packets are deployed, as
their entire purpose is to change the number of packets being sent to
adapt to known limitations of the network, but is not necessarily
valid in general.
The rewritten RTCP ECN feedback report is sent from the other side of
the translator to that which it arrived (as part of a compound RTCP
packet containing other translated RTCP packets, where appropriate).
The RTCP XR Report Block for the ECN nonce is used to convey the ECN
nonce and an explicit bit vector of which packets were ECN marked.
It is not meaningful to translate this report block, since it relates
to particular packets that only exist on one side of the translator.
An RTP translator MAY silently drop ECN nonce report blocks when
translating RTCP packets, or it MAY consume ECN nonce report blocks
received from downstream, and generate its own ECN nonce reports to
send upstream, based on its reception of the media stream. If the
RTP translator is a party to the signalling exchange, ECN nonce
SHOULD NOT be negotiated.
6.2. Generating RTCP ECN Feedback in Media Transcoders
An RTP translator that acts as a media transcoder cannot directly An RTP translator that acts as a media transcoder cannot directly
forward RTCP packets corresponding to the transcoded stream, since forward RTCP packets corresponding to the transcoded stream, since
those packets will relate to the non-transcoded stream, and will not those packets will relate to the non-transcoded stream, and will not
be useful in relation to the transcoded RTP flow. Such a transcoder be useful in relation to the transcoded RTP flow. Such a transcoder
will need to interpose itself into the RTCP flow, acting as a proxy will need to interpose itself into the RTCP flow, acting as a proxy
for the receiver to generate RTCP feedback in the direction of the for the receiver to generate RTCP feedback in the direction of the
sender relating to the pre-transcoded stream, and acting in place of sender relating to the pre-transcoded stream, and acting in place of
the sender to generate RTCP relating to the transcoded stream, to be the sender to generate RTCP relating to the transcoded stream, to be
sent towards the receiver. This section describes how this proxying sent towards the receiver. This section describes how this proxying
is to be done for RTCP ECN feedback packets. Section 7.2 of is to be done for RTCP ECN feedback packets. Section 7.2 of
[RFC3550] describes general procedures for other RTCP packet types. [RFC3550] describes general procedures for other RTCP packet types.
(tbd: complete this section) An RTP translator acting as a media transcoder in this manner does
not have its own SSRC, and hence is not visible to other entities at
the RTP layer. RTCP ECN feedback packets, RTCP XR report blocks for
ECN summary information, and RTCP XR report blocks for the ECN nonce
that are received from downstream relate to the translated stream,
and so must be processed by the translator as if it were the original
media source. These reports drive the congestion control loop and
media adaptation between the translator and the downstream receiver.
If there are multiple downstream receivers, a logically separate
transcoder instance must be used for each receiver, and must process
RTCP ECN feedback and summary reports independently to the other
transcoder instances. An RTP translator acting as a media transcoder
in this manner MUST NOT forward RTCP ECN feedback packets, RTCP XR
ECN summary reports, or RTCP XR ECN nonce reports from downstream
receivers in the upstream direction.
An RTP translator acting as a media transcoder will generate RTCP
reports upstream towards the original media sender, based on the
reception quality of the original media stream at the translator.
The translator will run a separate congestion control loop and media
adaptation between itself and the media sender for each of its
downstream receivers, and must generate RTCP ECN feedback packets and
RTCP XR ECN summary reports (and RTCP XR ECN nonce reports, if
desired) for that congestion control loop using the SSRC of that
downstream receiver.
6.3. Generating RTCP ECN Feedback in Mixers 6.3. Generating RTCP ECN Feedback in Mixers
An RTP mixer terminates one-or-more RTP flows, combines them into a An RTP mixer terminates one-or-more RTP flows, combines them into a
single outgoing media stream, and transmits that new stream as a single outgoing media stream, and transmits that new stream as a
separate RTP flow. An ECN-aware RTP mixer must send RTCP reports and separate RTP flow. A mixer has its own SSRC, and is visible to other
provide ECN feedback for the RTP flows it terminates, and must participants in the session at the RTP layer.
generate RTCP reports for the RTP flow it originates, and add ECT
marks to the outgoing packets. This section describes how RTCP is
processed in RTP mixers, and how that interacts with ECN feedback.
(tbd: complete this section) An ECN-aware RTP mixer must generate RTCP ECN feedback packets and
RTCP XR report blocks for ECN summary information relating to the RTP
flows it terminates, in exactly the same way it would if it were an
RTP receiver. An ECN-aware RTP mixer can optionally generate RTCP XR
report blocks containing ECN nonce information. These reports form
part of the congestion control loop between the mixer and the media
senders generating the streams it is mixing. A separate control loop
runs between each sender and the mixer.
An ECN-aware RTP mixer will negotiate and initiate the use of ECN on
the mixed flows it generates, and will accept and process RTCP ECN
feedback reports, RTCP XR report blocks for ECN, and RTCP XR report
blocks for the ECN nonce relating to those mixed flows as if it were
a standard media sender. A congestion control loop runs between the
mixer and its receivers, driven in part by the ECN reports received.
An RTP mixer MUST NOT forward RTCP ECN feedback packets, RTCP XR ECN
summary reports, or RTCP XR ECN nonce reports from downstream
receivers in the upstream direction.
7. Implementation considerations 7. Implementation considerations
To allow the use of ECN with RTP over UDP, the RTP implementation To allow the use of ECN with RTP over UDP, the RTP implementation
must be able to set the ECT bits in outgoing UDP datagrams, and must must be able to set the ECT bits in outgoing UDP datagrams, and must
be able to read the value of the ECT bits on received UDP datagrams. be able to read the value of the ECT bits on received UDP datagrams.
The standard Berkeley sockets API pre-dates the specification of ECN, The standard Berkeley sockets API pre-dates the specification of ECN,
and does not provide the functionality which is required for this and does not provide the functionality which is required for this
mechanism to be used with UDP flows, making this specification mechanism to be used with UDP flows, making this specification
difficult to implement portably. difficult to implement portably.
skipping to change at page 39, line 31 skipping to change at page 41, line 48
ECN-CE marked and its calculation of the ECN-none. This is mostly ECN-CE marked and its calculation of the ECN-none. This is mostly
not considered sensitive information. If considered sensitive the not considered sensitive information. If considered sensitive the
RTCP feedback shall be encrypted. RTCP feedback shall be encrypted.
Changing the ECN bits An on-path attacker that see the RTP packet Changing the ECN bits An on-path attacker that see the RTP packet
flow from sender to receiver and who has the capability to change flow from sender to receiver and who has the capability to change
the packets can rewrite ECT into ECN-CE thus forcing the sender or the packets can rewrite ECT into ECN-CE thus forcing the sender or
receiver to take congestion control response. This denial of receiver to take congestion control response. This denial of
service against the media quality in the RTP session is impossible service against the media quality in the RTP session is impossible
for en end-point to protect itself against. Only network for en end-point to protect itself against. Only network
infrastructure nodes can detect this illicit remarking. It will infrastructure nodes can detect this illicit re-marking. It will
be mitigated by turning off ECN, however, if the attacker can be mitigated by turning off ECN, however, if the attacker can
modify its response to drop packets the same vulnerability exist. modify its response to drop packets the same vulnerability exist.
Denial of Service affecting the session set-up signalling: If an Denial of Service affecting the session set-up signalling: If an
attacker can modify the session signalling it can prevent the attacker can modify the session signalling it can prevent the
usage of ECN by removing the signalling attributes used to usage of ECN by removing the signalling attributes used to
indicate that the initiator is capable and willing to use ECN with indicate that the initiator is capable and willing to use ECN with
RTP/UDP. This attack can be prevented by authentication and RTP/UDP. This attack can be prevented by authentication and
integrity protection of the signalling. We do note that any integrity protection of the signalling. We do note that any
attacker that can modify the signalling has more interesting attacker that can modify the signalling has more interesting
skipping to change at page 42, line 5 skipping to change at page 44, line 19
1. The negotiation and directionality attribute is going to need 1. The negotiation and directionality attribute is going to need
some consideration for multi-party sessions when readonly some consideration for multi-party sessions when readonly
capability might be sufficient to enable ECN for all incoming capability might be sufficient to enable ECN for all incoming
streams. However, it would beneficial to know if no potential streams. However, it would beneficial to know if no potential
sender support setting ECN. sender support setting ECN.
2. Consider initiation optimizations that allows for multi SSRC 2. Consider initiation optimizations that allows for multi SSRC
sender nodes to still have rapid usage of ECN. sender nodes to still have rapid usage of ECN.
3. Feedback suppression for ECN-CE, both for groups, and in case an
additional CE mark arrives within a RTT at the receiver.
12. References 12. References
12.1. Normative References 12.1. Normative References
[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.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
skipping to change at page 42, line 30 skipping to change at page 44, line 41
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003. November 2003.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245,
April 2010.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [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.
12.2. Informative References 12.2. Informative References
[I-D.ietf-avt-rtp-no-op] [I-D.ietf-avt-rtp-no-op]
Andreasen, F., "A No-Op Payload Format for RTP", Andreasen, F., "A No-Op Payload Format for RTP",
draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007.
[I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-tsvwg-ecn-tunnel] [I-D.ietf-tsvwg-ecn-tunnel]
Briscoe, B., "Tunnelling of Explicit Congestion Briscoe, B., "Tunnelling of Explicit Congestion
Notification", draft-ietf-tsvwg-ecn-tunnel-08 (work in Notification", draft-ietf-tsvwg-ecn-tunnel-08 (work in
progress), March 2010. progress), March 2010.
[I-D.zimmermann-avt-zrtp] [I-D.zimmermann-avt-zrtp]
Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Secure RTP", Path Key Agreement for Unicast Secure RTP",
draft-zimmermann-avt-zrtp-17 (work in progress), draft-zimmermann-avt-zrtp-22 (work in progress),
January 2010. June 2010.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
 End of changes. 72 change blocks. 
248 lines changed or deleted 374 lines changed or added

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