draft-ietf-avt-ecn-for-rtp-02.txt   draft-ietf-avt-ecn-for-rtp-03.txt 
Network Working Group M. Westerlund Network Working Group M. Westerlund
Internet-Draft I. Johansson Internet-Draft I. Johansson
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: January 11, 2011 C. Perkins Expires: April 28, 2011 C. Perkins
University of Glasgow University of Glasgow
P. O'Hanlon P. O'Hanlon
UCL UCL
K. Carlberg K. Carlberg
G11 G11
July 10, 2010 October 25, 2010
Explicit Congestion Notification (ECN) for RTP over UDP Explicit Congestion Notification (ECN) for RTP over UDP
draft-ietf-avt-ecn-for-rtp-02 draft-ietf-avt-ecn-for-rtp-03
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 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.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 11, 2011. This Internet-Draft will expire on April 28, 2011.
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
skipping to change at page 2, line 13 skipping to change at page 2, line 13
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 . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
4. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 9 4. Overview of Use of ECN with RTP/UDP/IP . . . . . . . . . . . . 10
4.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 12 5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 13
4.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 17 5.1. RTP/AVPF Transport Layer ECN Feedback packet . . . . . . . 13
4.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 22 5.2. RTCP XR Report block for ECN summary information . . . . . 16
4.4. Detecting Failures and Receiver Misbehaviour . . . . . . . 26 6. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 17
5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 29 6.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 17
5.1. ECN Feedback packet . . . . . . . . . . . . . . . . . . . 29 6.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 21
5.2. RTCP XR Report block for ECN summary information . . . . . 32 6.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 27
5.3. RTCP XR Report Block for ECN Nonce . . . . . . . . . . . . 33 6.4. Detecting Failures . . . . . . . . . . . . . . . . . . . . 29
6. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 36 7. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 33
6.1. Fragmentation and Reassembly in Translators . . . . . . . 36 7.1. Fragmentation and Reassembly in Translators . . . . . . . 33
6.2. Generating RTCP ECN Feedback in Media Transcoders . . . . 38 7.2. Generating RTCP ECN Feedback in Media Transcoders . . . . 35
6.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 39 7.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 36
7. Implementation considerations . . . . . . . . . . . . . . . . 40 8. Implementation considerations . . . . . . . . . . . . . . . . 36
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
8.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 40 9.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 37
8.2. AVPF Transport Feedback Message . . . . . . . . . . . . . 40 9.2. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 37
8.3. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 40 9.3. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 37
8.4. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 41 9.4. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 37
8.5. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 41 9.5. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 38
10. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 43 11. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 40
11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 44 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 40
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41
12.1. Normative References . . . . . . . . . . . . . . . . . . . 44 13.1. Normative References . . . . . . . . . . . . . . . . . . . 41
12.2. Informative References . . . . . . . . . . . . . . . . . . 45 13.2. Informative References . . . . . . . . . . . . . . . . . . 42
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
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 a feedback mechanism. The solution consists of which use RTCP as a feedback mechanism. The solution consists of
feedback of ECN congestion experienced markings to the sender using feedback of ECN congestion experienced markings to the sender using
RTCP, verification of ECN functionality end-to-end, and how to RTCP, verification of ECN functionality end-to-end, and how to
initiate ECN usage. The initiation process will have some initiate ECN usage. The initiation process will have some
dependencies on the signalling mechanism used to establish the RTP dependencies on the signalling mechanism used to establish the RTP
session, a specification for signalling mechanisms using SDP is session, a specification for signalling mechanisms using SDP is
included. 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 react in a controlled
manner, rather than responding to uncontrolled packet loss, and so ECN provides a way for networks to send congestion control signals to
improves the user experience while benefiting the network. By a media transport without having to impair the media. Unlike losses,
default, this reaction can be expected to be in the form of reducing the signals unambiguously indicate congestion to the transport as
the transmission rate. In addition, the use of ECN support outlined quickly as feedback delays allow, and without confusing congestion
in this document helps minimize the disruption of the flow (and the with losses that might have occurred for other reasons such as
user experience) by rapidly conveying congested conditions without transmission errors, packet-size errors, routing errors, badly
packet loss. implemented middleboxes, policy violations and so forth.
The introduction of ECN into the Internet requires changes to both The introduction of ECN into the Internet requires changes to both
the network and transport layers. At the network layer, IP the network and transport layers. At the network layer, IP
forwarding has to be updated to allow routers to mark packets, rather forwarding has to be updated to allow routers to mark packets, rather
than discarding them in times of congestion [RFC3168]. In addition, than discarding them in times of congestion [RFC3168]. In addition,
transport protocols have to be modified to inform the sender that ECN transport protocols have to be modified to inform the sender that ECN
marked packets are being received, so it can respond to the marked packets are being received, so it can respond to the
congestion. TCP [RFC3168], SCTP [RFC4960] and DCCP [RFC4340] have congestion. 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 mechanisms directly in UDP. Instead is due to the lack of feedback mechanisms directly in UDP. Instead
the signaling control protocol on top of UDP needs to provide that the signaling control protocol on top of UDP needs to provide that
feedback, which for 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. Section 4 provides an overview of how ECN is used with
defined in Section 4, along with RTCP extensions for ECN feedback in RTP over UDP. Then the definition of the RTCP extensions for ECN
Section 5. In Section 6 we discuss how RTCP ECN feedback is handled feedback in Section 5. Then the full details of how ECN is used with
in RTP translators and mixers. Section 7 discusses some RTP over UDP is defined in Section 6. In Section 7 we discuss how
implementation considerations, Section 8 lists IANA considerations, RTCP ECN feedback is handled in RTP translators and mixers.
and Section 9 discusses the security considerations. Section 8 discusses some implementation considerations, Section 9
lists IANA considerations, and Section 10 discusses the security
considerations.
2. Conventions, Definitions and Acronyms 2. Conventions, Definitions and Acronyms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Abbreviations Abbreviations
ECN: Explicit Congestion Notification o ECN: Explicit Congestion Notification
ECT: ECN Capable Transport o ECT: ECN Capable Transport
ECN-CE: ECN Congestion Experienced o ECN-CE: ECN Congestion Experienced
not-ECT: Not ECN Capable Transport o not-ECT: Not ECN Capable Transport
The meaning of the term ECN support depends on which entity between
the sender and receiver (inclusive) that is considered. We
distinguish between:
o ECN-Capable Host: Sender or receiver of media.
o ECN-Capable Transport: ECT = all ends are ECN capable hosts.
o ECN-Capable Packets: Packets are either ECT or CE.
o ECN-Oblivious Relay: Router or middlebox that treats ECN-Capable
Packets no differently from Not-ECT.
o ECN-Capable Queue: Supports ECN marking of ECN-Capable Packets.
o ECN-Blocking Middlebox: Discards ECN-Capable Packets.
o ECN-Reverting Middlebox: Changes ECN-Capable Packets to Not-ECT.
3. Discussion, Requirements, and Design Rationale 3. Discussion, Requirements, and Design Rationale
ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960], ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960],
and DCCP [RFC4340] transports. These are all unicast protocols which and DCCP [RFC4340] transports. These are all unicast protocols which
negotiate the use of ECN during the initial connection establishment negotiate the use of ECN during the initial connection establishment
handshake (supporting incremental deployment, and checking if ECN handshake (supporting incremental deployment, and checking if ECN
marked packets pass all middleboxes on the path). ECN Congestion marked packets pass all middleboxes on the path). ECN Congestion
Experienced (ECN-CE) marks are immediately echoed back to the sender Experienced (ECN-CE) marks are immediately echoed back to the sender
by the receiving end-point using an additional bit in feedback by the receiving end-point using an additional bit in feedback
skipping to change at page 4, line 50 skipping to change at page 5, line 25
Signalling: RTP relies on separate signalling protocols to negotiate Signalling: RTP relies on separate signalling protocols to negotiate
parameters before a session can be created, and doesn't include an parameters before a session can be created, and doesn't include an
in-band handshake or negotiation at session set-up time (i.e. in-band handshake or negotiation at session set-up time (i.e.
there is no equivalent to the TCP three-way handshake in RTP). there is no equivalent to the TCP three-way handshake in RTP).
Feedback: RTP does not explicitly acknowledge receipt of datagrams. Feedback: RTP does not explicitly acknowledge receipt of datagrams.
Instead, the RTP Control Protocol (RTCP) provides reception Instead, the RTP Control Protocol (RTCP) provides reception
quality feedback, and other back channel communication, for RTP quality feedback, and other back channel communication, for RTP
sessions. The feedback interval is generally on the order of sessions. The feedback interval is generally on the order of
seconds, rather than once per network RTT (although the RTP/AVPF seconds, rather than once per network RTT (although the RTP/AVPF
profile [RFC4585] allows more rapid feedback in some cases). profile [RFC4585] allows more rapid feedback in most cases).
Congestion Response: While it is possible to adapt the transmission Congestion Response: While it is possible to adapt the transmission
of many audio/visual streams in response to network congestion, of many audio/visual streams in response to network congestion,
and such adaptation is required by [RFC3550], the dynamics of the and such adaptation is required by [RFC3550], the dynamics of the
congestion response may be quite different to those of TCP or congestion response may be quite different to those of TCP or
other transport protocols. other transport protocols.
Middleboxes: The RTP framework explicitly supports the concept of Middleboxes: The RTP framework explicitly supports the concept of
mixers and translators, which are middleboxes that are involved in mixers and translators, which are middleboxes that are involved in
media transport functions. media transport functions.
Multicast: RTP is explicitly a group communication protocol, and was Multicast: RTP is explicitly a group communication protocol, and was
designed from the start to support IP multicast (primarily ASM, designed from the start to support IP multicast (primarily ASM,
although a recent extension supports SSM with unicast feedback). although a recent extension supports SSM with unicast feedback
[RFC5760]).
Application Awareness: ECN support via TCP, DCCP, and SCTP constrain Application Awareness: ECN support via TCP, DCCP, and SCTP constrain
the awareness and reaction to packet loss within those protocols. the awareness and reaction to packet loss within those protocols.
By adding support of ECN through RTCP, the application is made By adding support of ECN through RTCP, the application is made
aware of packet loss and may choose one or more approaches in aware of packet loss and may choose one or more approaches in
response to that loss. response to that loss.
Counting vs Detecting Congestion: TCP and the protocols derived from
it are mainly designed to respond the same whether they experience
a burst of congestion indications within one RTT or just one.
Whereas real-time applications may be concerned with the amount of
congestion experienced, whether it is distributed smoothly or in
bursts. When feedback of ECN was added to TCP [RFC3168], the
receiver was designed to flip the echo congestion experienced
(ECE) flag to 1 for a whole RTT then flop it back to zero.
Whereas ECN feedback in RTCP will need to report a count of how
much congestion has been experienced within an RTCP reporting
period, irrespective of round trip times.
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.
ECN support is more important for RTP sessions, since the impact of
packet loss in real-time audio-visual media flows is highly visible ECN support is more important for RTP sessions that for instance is
to users. Effective ECN support for RTP flows running over UDP will the case for TCP- This because the impact of packet loss in real-time
allow real-time audio-visual applications to respond to the onset of audio-visual media flows is highly visible to users. Effective ECN
congestion before routers are forced to drop packets, allowing those support for RTP flows running over UDP will allow real-time audio-
applications to control how they reduce their transmission rate, and visual applications to respond to the onset of congestion before
hence media quality, rather than responding to, and trying to conceal routers are forced to drop packets, allowing those applications to
the effects of, unpredictable packet loss. Furthermore, widespread control how they reduce their transmission rate, and hence media
deployment for ECN and active queue management in routers, should it quality, rather than responding to, and trying to conceal the effects
occur, can potentially reduce unnecessary queueing delays in routers, of, unpredictable packet loss. Furthermore, widespread deployment
lowering the round-trip time and benefiting interactive applications for ECN and active queue management in routers, should it occur, can
of RTP, such as voice telephony. potentially reduce unnecessary queueing delays in routers, lowering
the round-trip time and benefiting interactive applications 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, transport protocols supporting ECN, and RTP based
requirements that must be satisfied to at least some degree if ECN is applications one can create a set of requirements that must be
used by an other protocol (such as RTP over UDP) satisfied to at least some degree if ECN is to used by RTP over UDP.
o REQ 1: A mechanism MUST negotiate and initiate the usage of ECN o REQ 1: A mechanism MUST negotiate and initiate the usage of ECN
for RTP/UDP/IP sessions for RTP/UDP/IP sessions so that an RTP sender will not send
packets with ECT in the IP header unless it knows all potential
receivers will understand any CE indications they might receive.
o REQ 2: A mechanism MUST feedback the reception of any packets that o REQ 2: A mechanism MUST feedback the reception of any packets that
are ECN-CE marked to the packet sender are ECN-CE marked to the packet sender
o REQ 3: Provide mechanism SHOULD minimise the possibility for
o REQ 3: Provided mechanism SHOULD minimise the possibility for
cheating cheating
o REQ 4: Some detection and fallback mechanism SHOULD exist to avoid o REQ 4: Some detection and fallback mechanism SHOULD exist to avoid
loss of communication due to the attempted usage of ECN in case an loss of communication due to the attempted usage of ECN in case an
intermediate node clears ECT or drops packets that are ECT marked. intermediate node clears ECT or drops packets that are ECT marked.
o REQ 5: Negotiation of ECN SHOULD NOT significantly increase the o REQ 5: Negotiation of ECN SHOULD NOT significantly increase the
time taken to negotiate and set-up the RTP session (an extra RTT time taken to negotiate and set-up the RTP session (an extra RTT
before the media can flow is unlikely to be acceptable for some before the media can flow is unlikely to be acceptable for some
use cases). use cases).
skipping to change at page 6, line 34 skipping to change at page 7, line 28
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 various forms and at various nodes. As an adaptation can occur in various forms and at various nodes. As an
example, the sender can change the media encoding, or the receiver example, the sender can change the media encoding, or the receiver
can change the subscription to a layered encoding, or either reaction can change the subscription to a layered encoding, or either reaction
can be accomplished by a transcoding middlebox. RFC 5117 identifies can be accomplished by a transcoding middlebox. RFC 5117 identifies
seven topologies in which RTP sessions may be configured, and which seven topologies in which RTP sessions may be configured, and which
may affect the ability to use ECN: may affect the ability to use ECN:
Topo-Point-to-Point: This is a standard unicast flow. ECN may be Topo-Point-to-Point: This is a standard unicast flow. ECN may be
used with RTP in this topology in an analogous manner to its use used with RTP in this topology in an analogous manner to its use
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
to scale to large group sizes while avoiding feedback implosion to scale to large group sizes while avoiding feedback implosion
(see Section 6.2 of [RFC3550], [RFC4585], and [RFC5760]), and can (see Section 6.2 of [RFC3550], [RFC4585], and [RFC5760]), and can
be used by a sender to determine if all its receivers, and the be used by a sender to determine if all its receivers, and the
network paths to those receivers, support ECN (see Section 4.2). network paths to those receivers, support ECN (see Section 6.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 6.4
to monitor that all receivers continue to support ECN, and they to monitor that all receivers continue to support ECN, and they
need to fallback to non-ECN use if any senders 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
skipping to change at page 7, line 49 skipping to change at page 8, line 42
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
must manage the ECN bits in a way analogous to that described must manage the ECN bits in a way analogous to that described
in Section 5.3 of [RFC3168]: if an ECN marked packet is split in Section 5.3 of [RFC3168]: if an ECN marked packet is split
into two, then both the outgoing packets must be ECN marked into two, then both the outgoing packets must be ECN marked
identically to the original; if several ECN marked packets are identically to the original; if several ECN marked packets are
combined into one, the outgoing packet must be either ECN-CE combined into one, the outgoing packet must be either ECN-CE
marked or dropped if any of the incoming packets are ECN-CE marked or dropped if any of the incoming packets are ECN-CE
marked, and should be ECT marked if any of the incoming packets marked. If the outgoing combined packet is not ECN-CE marked,
are ECT marked. When RTCP ECN feedback packets (Section 5) are then it MUST be ECT marked if any of the incoming packets were
ECT marked. When RTCP ECN feedback packets (Section 5) are
received, they must be rewritten to match the modifications received, they must be rewritten to match the modifications
made to the media stream (see Section 6.1). made to the media stream (see Section 7.1).
* If the translator is a media transcoder, the output RTP media * If the translator is a media transcoder, the output RTP media
stream may have radically different characteristics than the stream may have radically different characteristics than the
input RTP media stream. Each side of the translator must then input RTP media stream. Each side of the translator must then
be considered as a separate transport connection, with its own be considered as a separate transport connection, with its own
ECN processing. This requires the translator interpose itself ECN processing. This requires the translator interpose itself
into the ECN negotiation process, effectively splitting the into the ECN negotiation process, effectively splitting the
connection into two parts with their own negotiation. Once connection into two parts with their own negotiation. Once
negotiation has been completed, the translator must generate negotiation has been completed, the translator must generate
RTCP ECN feedback back to the source based on its own RTCP ECN feedback back to the source based on its own
reception, and must respond to RTCP ECN feedback received from reception, and must respond to RTCP ECN feedback received from
the receiver(s) (see Section 6.2). the receiver(s) (see Section 7.2).
It is recognised that ECN and RTCP processing in an RTP translator It is recognised that ECN and RTCP processing in an RTP translator
that modifies the media stream is non-trivial. that modifies the media stream is non-trivial.
Topo-Mixer: A mixer is an RTP-level middlebox that aggregates Topo-Mixer: A mixer is an RTP-level middlebox that aggregates
multiple RTP streams, mixing them together to generate a new RTP multiple RTP streams, mixing them together to generate a new RTP
stream. The mixer is visible to the other participants in the RTP stream. The mixer is visible to the other participants in the RTP
session, and is also usually visible in the associated signalling session, and is also usually visible in the associated signalling
session. The RTP flows on each side of the mixer are treated session. The RTP flows on each side of the mixer are treated
independently for ECN purposes, with the mixer generating its own independently for ECN purposes, with the mixer generating its own
skipping to change at page 9, line 35 skipping to change at page 10, line 28
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. Overview of Use of ECN with RTP/UDP/IP
The solution for using ECN with RTP over UDP/IP consists of four The solution for using ECN with RTP over UDP/IP consists of four
different pieces that together make the solution work: different pieces that together make the solution work:
1. Negotiation of the capability to use ECN with RTP/UDP/IP 1. Negotiation of the capability to use ECN with RTP/UDP/IP
2. Initiation and initial verification of ECN capable transport 2. Initiation and initial verification of ECN capable transport
3. Ongoing use of ECN within an RTP session 3. Ongoing use of ECN within an RTP session
4. Failure detection, verification and fallback 4. Handling of dynamic groups through failure detection,
verification and fallback
The solution includes a new SDP attribute (Section 6.1.1), the
definition of new extensions to RTCP (Section 5) and STUN
(Section 6.2.2).
Before an RTP session can be created, a signalling protocol is used Before an RTP session can be created, a signalling protocol is used
to discover the other participants and negotiate session parameters to discover the other participants and negotiate session parameters
(see Section 4.1). One of the parameters that can be negotiated is (see Section 6.1). One of the parameters that can be negotiated is
the capability of a participant to support ECN functionality, or the capability of a participant to support ECN functionality, or
otherwise. Note that all participants having the capability of otherwise. Note that all participants having the capability of
supporting ECN does not necessarily imply that ECN is usable in an supporting ECN does not necessarily imply that ECN is usable in an
RTP session, since there may be middleboxes on the path between the RTP session, since there may be middleboxes on the path between the
participants which don't pass ECN-marked packets (for example, a participants which don't pass ECN-marked packets (for example, a
firewall that blocks traffic with the ECN bits set). This document firewall that blocks traffic with the ECN bits set). This document
defines the information that needs to be negotiated, and provides a defines the information that needs to be negotiated, and provides a
mapping to SDP for use in both declarative and offer/answer contexts. mapping to SDP for use in both declarative and offer/answer contexts.
When a sender joins a session for which all participants claim ECN When a sender joins a session for which all participants claim ECN
capability, it must verify if that capability is usable. There are capability, it must verify if that capability is usable. There are
three ways in which this verification may be done (Section 4.2): three ways in which this verification may be done (Section 6.2):
o The sender may generate a (small) subset of its RTP data packets o The sender may generate a (small) subset of its RTP data packets
with the ECN field set to ECT(0) or ECT(1). Each receiver will with the ECN field set to ECT(0) or ECT(1). Each receiver will
then send an RTCP feedback packet indicating the reception of the then send an RTCP feedback packet indicating the reception of the
ECT marked RTP packets. Upon reception of this feedback from each ECT marked RTP packets. Upon reception of this feedback from each
receiver it knows of, the sender can consider ECN functional for receiver it knows of, the sender can consider ECN functional for
its traffic. Each sender does this verification independently of its traffic. Each sender does this verification independently of
each other. If a new receiver joins an existing session it also each other. If a new receiver joins an existing session it will
needs to verify ECN support. If verification fails the sender reveal whether or not it supports ECN when it sends its first RTCP
needs to stop using ECN. As the sender will not know of the report to each source. If the RTCP report includes ECN
receiver prior to it sending RTP or RTCP packets, the sender will information, verification will have succeeeded and sources can
wait for the first RTCP packet from the new receiver to determine continue to send ECT packets. If not, verification fails and each
if that contains ECN feedback or not. sender MUST stop using ECN.
o Alternatively, ECN support can be verified during an initial end- o Alternatively, ECN support can be verified during an initial end-
to-end STUN exchange (for example, as part of ICE connection to-end STUN exchange (for example, as part of ICE connection
establishment). After having verified connectivity without ECN establishment). After having verified connectivity without ECN
capability an extra STUN exchange, this time with the ECN field capability an extra STUN exchange, this time with the ECN field
set to ECT(0) or ECT(1), is performed. If successful the path's set to ECT(0) or ECT(1), is performed. If successful the path's
capability to convey ECN marked packets is verified. A new STUN capability to convey ECN marked packets is verified. A new STUN
attribute is defined to convey feedback that the ECT marked STUN attribute is defined to convey feedback that the ECT marked STUN
request was received (see Section 8.4), along with an ICE request was received (see Section 9.4), along with an ICE
signalling option (Section 8.5). signalling option (Section 9.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 is not serious. The impact on the application where failure is not serious. The impact on the
network and other users must be considered when making a leap of network and other users must be considered when making a leap of
skipping to change at page 11, line 29 skipping to change at page 12, line 28
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 the receipt of new that are in place. This feedback report indicates the receipt of new
CE marks since the last ECN feedback packet, and also counts the CE marks since the last ECN feedback packet, and also counts the
total number of CE marked packets through a cumulative sum. This is total number of CE marked packets through a cumulative sum. This is
the mechanism to provide the fastest possible feedback to senders the mechanism to provide the fastest possible feedback to senders
about CE marks. On receipt of a CE marked packet, the system must about CE marks. On receipt of a CE marked packet, the system must
react to congestion as-if packet loss has been reported. Section 4.3 react to congestion as-if packet loss has been reported. Section 6.3
describes the ongoing use of 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, the RTCP ECN summary reports, is used to ensure additional procedure, the RTCP ECN summary reports, is used to ensure
more reliable, but less timely, reporting of the ECN information. more reliable, but less timely, reporting of the ECN information.
The ECN summary report contains the same information as the ECN The ECN summary report contains the same information as the ECN
feedback format, only packed differently for better efficiency with feedback format, only packed differently for better efficiency with
large reports. It is sent in a compound RTCP packet, along with large reports. It is sent in a compound RTCP packet, along with
regular RTCP reception reports. By using cumulative counters for regular RTCP reception reports. By using cumulative counters for
seen CE, ECT, not-ECT and packet loss the sender can determine what seen CE, ECT, not-ECT and packet loss the sender can determine what
skipping to change at page 12, line 13 skipping to change at page 13, line 12
followed by re-routing around it. Such an event may result in the followed by re-routing around it. Such an event may result in the
packet being sent through a node that is ECN non-compliant, thus re- packet being sent through a node that is ECN non-compliant, thus re-
marking or dropping packets with ECT set. To prevent this from marking or dropping packets with ECT set. To prevent this from
impacting the application for longer than necessary, the operation of impacting the application for longer than necessary, the operation of
ECN is constantly monitored by all senders. Both the RTCP ECN ECN is constantly monitored by all senders. 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 compare the number of ECT(0), ECT(1), and non-ECT marked packets
received with the number that were sent, while also reporting CE received with the number that were sent, while also reporting CE
marked and lost packets. If these numbers do not agree, 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 6.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 5. RTCP Extensions for ECN feedback
nonce over all received packets that were not ECN-CE marked or
reported explicitly lost. This provides an additional means to This documents defines two different RTCP extensions: one RTP/AVPF
detect any packet re-marking that happens in the network, and can [RFC4585] transport layer feedback format for urgent ECN information,
also be used by a sender to detect receivers that lie about reception and one RTCP XR [RFC3611] ECN summary report block type for regular
of CE-marked packets (it is to be noted that the incentive for reporting of the ECN marking information. The full definition of
receivers to lie in their ECN reports is low for RTP/UDP/IP sessions, these extensions usage as part of the complete solution is laid out
since increased congestion levels are likely to cause unpredictable in Section 6.
packet losses that decrease the media quality more than would
reducing the data rate). To enable the sender to verify the ECN 5.1. RTP/AVPF Transport Layer ECN Feedback packet
nonce, the sender must learn the sequence number of all packets that
was either CE marked or lost, otherwise it can't correctly exclude This RTP/AVPF transport layer feedback format is intended for usage
these packet from the ECN nonce sum. This is done using a new RTCP in AVPF early or immediate feedback modes when information needs to
XR report type, the Nonce Report, that contains the nonce sums and urgently reach the sender. Thus its main use is to report on
indicating the lost or ECN-CE marked packets using a run length reception of an ECN-CE marked RTP packet so that the sender may
encoded bit-vector (see Section 5.3). Due to the size of ECN Nonce perform congestion control, or to speed up the initiation procedures
Reports, and as most RTP-based applications have little incentive to by rapidly reporting that the path can support ECN-marked traffic.
lie about ECN marks, the use of the ECN nonce is OPTIONAL. The feedback format is also defined with reduced size RTCP [RFC5506]
in mind, where RTCP feedback packets may be sent without accompanying
Sender or Receiver Reports that would contain the Extended Highest
Sequence number and the accumulated number of packet losses. Both
are important for ECN to verify functionality and keep track of when
CE marking does occur.
The RTP/AVPF transport layer feedback packet starts with the common
header defined by the RTP/AVPF profile [RFC4585] which is reproduced
here for the reader's information:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT=RTPFB=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Figure 1: RTP/AVPF Common Packet Format for Feedback Messages
From Figure 1 it can be determined the identity of the feedback
provider and for which RTP packet sender it applies. Below is the
feedback information format defined that is inserted as FCI for this
particular feedback messages that is identified with an FMT value =
6.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Highest Sequence Number | Lost packets counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter | ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: ECN Feedback Format
The FCI information for the ECN Feedback format (Figure 2) are the
following:
Extended Highest Sequence Number: The least significant 20-bit from
an Extended highest sequence number received value as defined by
[RFC3550]. Used to indicate for which packet this report is valid
up to.
Lost Packets Counter: The cumulative number of RTP packets that the
receiver expected to receive from this SSRC, minus the number of
packets it actually received. This is the same as the cumulative
number of packets lost defined in Section 6.4.1 of [RFC3550]
except represented in 12-bit signed format, compared to 24-bit in
RTCP SR or RR packets. As with the equivalent value in RTCP SR or
RR packets, note that packets that arrive late are not counted as
lost, and the loss may be negative if there are duplicates.
CE Counter: The cumulative number of RTP packets received from this
SSRC since the receiver joined the RTP session that were ECN-CE
marked. The receiver should keep track of this value using a
local representation that is longer than 16-bits, and only include
the 16-bits with least significance. In other words, the field
will wrap to 0 if more than 65535 packets has been received.
ECT(0) Counter: The cumulative number of RTP packets received from
this SSRC since the receiver joined the RTP session that had an
ECN field value of ECT(0). The receiver should keep track of this
value using a local representation that is longer than 16-bits,
and only include the 16-bits with least significance. In other
words, the field will wrap if more than 65535 packets have been
received.
ECT(1) Counter: The cumulative number of RTP packets received from
this SSRC since the receiver joined the RTP session that had an
ECN field value of ECT(1). The receiver should keep track of this
value using a local representation that is longer than 16-bits,
and only include the 16-bits with least significance. In other
words, the field will wrap if more than 65535 packets have been
received.
not-ECT Counter: The cumulative number of RTP packets received from
this SSRC since the receiver joined the RTP session that had an
ECN field value of not-ECT. The receiver should keep track of
this value using a local representation that is longer than 16-
bits, and only include the 16-bits with least significance. In
other words, the field will wrap if more than 65535 packets have
been received.
Each FCI block reports on a single source (SSRC). Multiple sources
can be reported by including multiple RTCP feedback messages in an
compound RTCP packet. The AVPF common header indicates both the
sender of the feedback message and on which stream it relates to.
The Counters SHALL be initiated to 0 for a new receiver. This to
enable detection of CE or Packet loss already on the initial report
from a specific participant.
The Extended Highest sequence number and packet loss fields are both
truncated in comparison to the RTCP SR or RR versions. This is to
save bits as the representation is redundant unless reduced size RTCP
is used in such a way that only feedback packets are transmitted,
with no SR or RR in the compound RTCP packet. Due to that regular
RTCP reporting will include the longer versions of the fields the
wrapping issue will be less unless the packet rate of the application
is so high that the fields will wrap within a regular RTCP reporting
interval. In those case the feedback packet need to be sent in a
compound packet together with the SR or RR packet.
There is an issue with packet duplication in relation to the packet
loss counter. If one avoids holding state for which sequence number
has been received then the way one can count loss is to count the
number of received packets and compare that to the number of packets
expected. As a result a packet duplication can hide a packet loss.
If a receiver is tracking the sequence numbers actually received and
suppresses duplicates it provides for a more reliable packet loss
indication. Reordering may also result in that packet loss is
reported in one report and then removed in the next.
The CE counter is actually more robust for packet duplication.
Adding each received CE marked packet to the counter is not an issue.
If one of the clones was CE marked that is still a indication of
congestion. Packet duplication has potential impact on the ECN
verification. Thus the sum of packets reported may be higher than
the number sent. However, most detections are still applicable.
5.2. RTCP XR Report block for ECN summary information
This report block combined with RTCP SR or RR report blocks carries
the same information as the ECN Feedback Packet and shall be based on
the same underlying information. However, there is a difference in
semantics between the feedback format and this XR version. Where the
feedback format is intended to report on a CE mark as soon as
possible, this extended report is for the regular RTCP report and
continuous verification of the ECN functionality end-to-end.
The ECN Summary report block consists of one report block header:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and then followed of one or more of the following report data blocks:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter | ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BT: Block Type identifying the ECN summary report block. Value is
13.
Reserved: All bits SHALL be set to 0 on transmission and ignored on
reception.
Block Length: The length of the report block. Used to indicate the
number of report data blocks present in the ECN summary report.
This length will be 3*n, where n is the number of ECN summary
report blocks, since blocks are a fixed size.
SSRC of Media Sender: The SSRC identifying the media sender this
report is for.
CE Counter: as in Section 5.1.
ECT(0) Counter: as in Section 5.1.
ECT(1) Counter: as in Section 5.1.
not-ECT Counter: as in Section 5.1.
The Extended Highest Sequence number and the packet loss counter for
each SSRC is not present in RTCP XR report, in contrast to the
feedback version. The reason is that this summary report will always
be sent in a RTCP compound packet where the Extended Highest Sequence
number and the accumulated number of packet losses are present in the
RTCP Sender Report or Receiver Report packet's report block.
6. Use of ECN with RTP/UDP/IP
In the detailed specification of the behaviour below, the different In the detailed specification of the behaviour below, the different
functions in the general case will first be discussed. In case functions in the general case will first be discussed. In case
special considerations are needed for middleboxes, multicast usage special considerations are needed for middleboxes, multicast usage
etc, those will be specially discussed in related subsections. etc, those will be specially discussed in related subsections.
4.1. Negotiation of ECN Capability 6.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
used symmetrically, the method for initial ECT verification, and used symmetrically and the method for initial ECT verification This
whether the ECN nonce is to be used. This memo defines the mappings memo defines the mappings of this information onto SDP for both
of this information onto SDP for both declarative and offer/answer declarative and offer/answer usage. There is one SDP extension to
usage. There is one SDP extension to indicate if ECN support should indicate if ECN support should be used, and the method for
be used, and the method for initiation. In addition an ICE parameter initiation. In addition an ICE parameter is defined to indicate that
is defined to indicate that ECN initiation using STUN is supported as ECN initiation using STUN is supported as part of an ICE exchange.
part of an ICE exchange.
An RTP system that supports ECN and uses SDP in the signalling MUST An RTP system that supports ECN and uses SDP in the signalling MUST
implement the SDP extension to signal ECN capability as described in implement the SDP extension to signal ECN capability as described in
Section 4.1.1. It MAY also implement alternative ECN capability Section 6.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 6.1.2.
4.1.1. Signalling ECN Capability using SDP 6.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 of ECN initiation to be to support ECN, and to negotiate the method of ECN initiation to be
used in the session. The attribute takes a list of initiation used in the session. The attribute takes a list of initiation
methods, ordered in decreasing preference. The defined values for methods, ordered in decreasing preference. The defined values for
the initiation method are: the initiation method are:
rtp: Using RTP and RTCP as defined in Section 4.2.1. rtp: Using RTP and RTCP as defined in Section 6.2.1.
ice: Using STUN within ICE as defined in Section 4.2.2. ice: Using STUN within ICE as defined in Section 6.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 6.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:
o The "mode" parameter signals the endpoint's capability to set and mode: This parameter signals the endpoint's capability to set and
read ECN marks in UDP packets. An examination of various read ECN marks in UDP packets. An examination of various
operating systems has shown that end-system support for ECN operating systems has shown that end-system support for ECN
marking of UDP packets may be symmetric or asymmetric. By this we marking of UDP packets may be symmetric or asymmetric. By this we
mean that some systems may allow end points to set the ECN bits in mean that some systems may allow end points to set the ECN bits in
an outgoing UDP packet but not read them, while others may allow an outgoing UDP packet but not read them, while others may allow
applications to read the ECN bits but not set them. This applications to read the ECN bits but not set them. This
either/or case may produce an asymmetric support for ECN and thus either/or case may produce an asymmetric support for ECN and thus
should be conveyed in the SDP signalling. The "mode=setread" should be conveyed in the SDP signalling. The "mode=setread"
state is the ideal condition where an endpoint can both set and state is the ideal condition where an endpoint can both set and
read ECN bits in UDP packets. The "mode=setonly" state indicates read ECN bits in UDP packets. The "mode=setonly" state indicates
skipping to change at page 14, line 8 skipping to change at page 19, line 5
occurred. The "mode=readonly" state indicates that the endpoint occurred. The "mode=readonly" state indicates that the endpoint
can read the ECN bits to determine if downstream congestion has can read the ECN bits to determine if downstream congestion has
occurred, but it cannot set the ECT bits in outgoing UDP packets. occurred, but it cannot set the ECT bits in outgoing UDP packets.
When the "mode=" parameter is omitted it is assumed that the node When the "mode=" parameter is omitted it is assumed that the node
has "setread" capabilities. This option can provide for an early has "setread" capabilities. This option can provide for an early
indication that ECN cannot be used in a session. This would be indication that ECN cannot be used in a session. This would be
case when both the offerer and answerer set the "mode=" parameter case when both the offerer and answerer set the "mode=" parameter
to "setonly" or "readonly", or when an RTP sender entity considers to "setonly" or "readonly", or when an RTP sender entity considers
offering "readonly". offering "readonly".
o The "nonce" parameter may be used to signal whether the ECN nonce ect: This parameter makes it possible to express the preferred ECT
is to be used in the session. This parameter takes two values;
"nonce=1" for nonce proposed or shall be used, and "nonce=0" for
no nonce. If this parameter is not specified, the default is no
nonce.
o The "ect" parameter makes it possible to express the preferred ECT
marking. This is either "random", "0", or "1", with "0" being marking. This is either "random", "0", or "1", with "0" being
implied if not specified. The "ect" parameter describes a implied if not specified. The "ect" parameter describes a
receiver preference, and is useful in the case where the receiver receiver preference, and is useful in the case where the receiver
knows it is behind a link using IP header compression, the knows it is behind a link using IP header compression, the
efficiency of which would be seriously disrupted if it were to efficiency of which would be seriously disrupted if it were to
receive packets with randomly chosen ECT marks. If the ECN nonce receive packets with randomly chosen ECT marks. Iit is
is used then this parameter MUST be ignored, and random ECT is RECOMMENDED that ECT(0) marking be used.
implied; if the ECN nonce is not used, it is RECOMMENDED that
ECT(0) marking be used.
The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp" attribute is The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp" attribute is
as follows: as follows:
ecn-attribute = "a=ecn-capable-rtp:" SP init-list SP parm-list ecn-attribute = "a=ecn-capable-rtp:" SP init-list SP parm-list
init-list = init-value *("," init-value) init-list = init-value *("," init-value)
init-value = "rtp" / "ice" / "leap" / init-ext init-value = "rtp" / "ice" / "leap" / init-ext
init-ext = token init-ext = token
parm-list = parm-value *(";" SP parm-value) parm-list = parm-value *(";" SP parm-value)
parm-value = nonce / mode / ect / parm-ext parm-value = mode / ect / parm-ext
mode = "mode=" ("setonly" / "setread" / "readonly") mode = "mode=" ("setonly" / "setread" / "readonly")
nonce = "nonce=" ("0" / "1") ect = "ect=" ("0" / "1")
ect = "ect=" ("random" / "0" / "1")
parm-ext = parm-name "=" parm-value-ext parm-ext = parm-name "=" parm-value-ext
parm-name = token parm-name = token
parm-value-ext = token / quoted-string parm-value-ext = token / quoted-string
quoted-string = DQUOTE *qdtext DQUOTE quoted-string = DQUOTE *qdtext DQUOTE
qdtext = %x20-21 / %x23-7E / %x80-FF qdtext = %x20-21 / %x23-7E / %x80-FF
; any 8-bit ascii except <"> ; any 8-bit ascii except <">
; external references: ; external references:
; token: from RFC 4566 ; token: from RFC 4566
; SP and DQUOTE from RFC 5234 ; SP and DQUOTE from RFC 5234
skipping to change at page 15, line 44 skipping to change at page 20, line 31
If the "mode=setread" parameter is present in the "a=ecn-capable-rtp" If the "mode=setread" parameter is present in the "a=ecn-capable-rtp"
attribute of the offer and the answering party is "setonly", then ECN attribute of the offer and the answering party is "setonly", then ECN
may only be initiated in the direction from the answering party to may only be initiated in the direction from the answering party to
the offering party. If the offering party is "mode=setread" but the the offering party. If the offering party is "mode=setread" but the
answering party is "mode=readonly", then ECN may only be initiated in answering party is "mode=readonly", then ECN may only be initiated in
the direction from the offering party to the answering party. If the direction from the offering party to the answering party. If
both offer and answer are "mode=setread", then ECN may be initiated both offer and answer are "mode=setread", then ECN may be initiated
in both directions. Note that "mode=setread" is implied by the in both directions. Note that "mode=setread" is implied by the
absence of a "mode=" parameter in the offer or the answer. absence of a "mode=" parameter in the offer or the answer.
If the "nonce=1" parameter is present in the "a=ecn-capable-rtp"
attribute of the offer, the answer MUST explicitly include the
"nonce=" parameter in the "a=ecn-capable-rtp" attribute of the answer
to indicate if it supports the ECN nonce. If the answer indicates
support ("nonce=1") then ECN nonce SHALL be used in the session; if
the answer does not include the "nonce=" parameter, or includes
"nonce=0", then the ECN nonce SHALL NOT be used. The answer MAY
include a "nonce=0" parameter in an answer even if not included in
the offer. This indicates that the answerer supports and is
interested in using ECN-nonce in this session, but it is not
currently enabled. If the offerer supports use of the nonce then it
SHOULD run a second round of offer/answer to enable use of the ECN
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 the Session Announcement Protocol (SAP, [RFC2974]), session using the Session Announcement Protocol (SAP, [RFC2974]),
negotiation of session description parameters is not possible. The negotiation of session description parameters is not possible. The
"a=ecn-capable-rtp" attribute MAY be added to the session description "a=ecn-capable-rtp" attribute MAY be added to the session description
to indicate that the sender will use ECN in the RTP session. The to indicate that the sender will use ECN in the RTP session. The
attribute MUST include a single method of initiation. Participants attribute MUST include a single method of initiation. Participants
MUST NOT join such a session unless they have the capability to MUST NOT join such a session unless they have the capability to
understand ECN-marked UDP packets, implement the method of understand ECN-marked UDP packets, implement the method of
initiation, and can generate RTCP ECN feedback (note that having the initiation, and can generate RTCP ECN feedback (note that having the
capability to use ECN doesn't necessarily imply that the underlying capability to use ECN doesn't necessarily imply that the underlying
network path between sender and receiver supports ECN). If the nonce network path between sender and receiver supports ECN). The mode
parameter is included then the ECN nonce SHALL be used in the parameter MAY be included also in declarative usage, to indicate
session. The mode parameter MAY be included also in declarative which capability is required by the consumer of the SDP. So for
usage, to indicate which capability is required by the consumer of example in a SSM session the participants configured with a
the SDP. So for example in a SSM session the participants configured particular SDP will all be in a media receive only mode, thus
with a particular SDP will all be in a media receive only mode, thus
mode=readonly will work as the capability of reporting on the ECN mode=readonly will work as the capability of reporting on the ECN
markings in the received is what is required. 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 6.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] or other profile that inherits
AVPF's signalling rules, MUST be signalled.
When using ECN nonce, the RTCP XR signalling indicating the ECN Nonce
report MUST also be included in the SDP [RFC3611].
4.1.2. ICE Parameter to Signal ECN Capability 6.1.2. ICE Parameter to Signal ECN Capability
One new ICE [RFC5245] option, "rtp+ecn", is defined. This is used One new ICE [RFC5245] option, "rtp+ecn", is defined. This is used
with the SDP session level "a=ice-options" attribute in an SDP offer with the SDP session level "a=ice-options" attribute in an SDP offer
to indicate that the initiator of the ICE exchange has the capability to indicate that the initiator of the ICE exchange has the capability
to support ECN for RTP-over-UDP flows (via "a=ice-options: rtp+ecn"). to support ECN for RTP-over-UDP flows (via "a=ice-options: rtp+ecn").
The answering party includes this same attribute at the session level The answering party includes this same attribute at the session level
in the SDP answer if it also has the capability, and removes the in the SDP answer if it also has the capability, and removes the
attribute if it does not wish to use ECN, or doesn't have the attribute if it does not wish to use ECN, or doesn't have the
capability to use ECN. If this initiation method (Section 4.2.2) capability to use ECN. If this initiation method (Section 6.2.2)
actually is going to be used, it is explicitly negotiated using the actually is going to be used, it is explicitly 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 6.2. Initiation of ECN Use in an RTP Session
Once the sender and the receiver(s) have agreed that they have the Once the sender and the receiver(s) have agreed that they have the
capability to use ECN within a session, they may attempt to initiate capability to use ECN within a session, they may attempt to initiate
ECN use. ECN use.
At the start of the RTP session, when the first packets with ECT are At the start of the RTP session, when the first packets with ECT are
sent, it is important to verify that IP packets with ECN field values sent, it is important to verify that IP packets with ECN field values
of ECT or ECN-CE will reach their destination(s). There is some risk of ECT or ECN-CE will reach their destination(s). There is some risk
that the use of ECN will result in either reset of the ECN field, or that the use of ECN will result in either reset of the ECN field, or
loss of all packets with ECT or ECN-CE markings. If the path between loss of all packets with ECT or ECN-CE markings. If the path between
the sender and the receivers exhibits either of these behaviours one the sender and the receivers exhibits either of these behaviours one
needs to stop using ECN immediately to protect both the network and needs to stop using ECN immediately to protect both the network and
the application. the application.
The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic
at any time. This is to ensure that packet loss due to ECN marking at any time. This is to ensure that packet loss due to ECN marking
will not effect the RTCP traffic and the necessary feedback will not effect the RTCP traffic and the necessary feedback
information it carries. information it carries.
An RTP system that supports ECN MUST implement the initiation of ECN An RTP system that supports ECN MUST implement the initiation of ECN
using in-band RTP and RTCP described in Section 4.2.1. It MAY also using in-band RTP and RTCP described in Section 6.2.1. It MAY also
implement other mechanisms to initiate ECN support, for example the implement other mechanisms to initiate ECN support, for example the
STUN-based mechanism described in Section 4.2.2 or use the leap of STUN-based mechanism described in Section 6.2.2 or use the leap of
faith option if the session supports the limitations provided in faith option if the session supports the limitations provided in
Section 4.2.3. If support for both in-band and out-of-band Section 6.2.3. If support for both in-band and out-of-band
mechanisms is signalled, the sender should try ECN negotiation using mechanisms is signalled, the sender should try ECN negotiation using
STUN with ICE first, and if it fails, fallback to negotiation using STUN with ICE first, and if it fails, fallback to negotiation using
RTP and RTCP ECN feedback. RTP and RTCP ECN feedback.
No matter how ECN usage is initiated, the sender MUST continually No matter how ECN usage is initiated, the sender MUST continually
monitor the ability of the network, and all its receivers, to support monitor the ability of the network, and all its receivers, to support
ECN, following the mechanisms described in Section 4.4. This is ECN, following the mechanisms described in Section 6.4. This is
necessary because path changes or changes in the receiver population necessary because path changes or changes in the receiver population
may invalidate the ability of the network to support ECN. may invalidate the ability of the system to use ECN.
4.2.1. Detection of ECT using RTP and RTCP 6.2.1. Detection of ECT using RTP and RTCP
The ECN initiation phase using RTP and RTCP to detect if the network The ECN initiation phase using RTP and RTCP to detect if the network
path supports ECN comprises three stages. Firstly, the RTP sender path supports ECN comprises three stages. Firstly, the RTP sender
generates some small fraction of its traffic with ECT marks to act a generates some small fraction of its traffic with ECT marks to act a
probe for ECN support. Then, on receipt of these ECT-marked packets, probe for ECN support. Then, on receipt of these ECT-marked packets,
the receivers send RTCP ECN feedback packets and RTCP ECN summary the receivers send RTCP ECN feedback packets and RTCP ECN summary
reports to inform the sender that their path supports ECN. Finally, reports to inform the sender that their path supports ECN. Finally,
the RTP sender makes the decision to use ECN or not, based on whether the RTP sender makes the decision to use ECN or not, based on whether
the paths to all RTP receivers have been verified to support ECN. the paths to all RTP receivers have been verified to support ECN.
Generating ECN Probe Packets: During the ECN initiation phase, an Generating ECN Probe Packets: During the ECN initiation phase, an
RTP sender SHALL mark a small fraction of its RTP traffic as ECT, RTP sender SHALL mark a small fraction of its RTP traffic as ECT,
while leaving the reminder of the packets unmarked. The main while leaving the reminder of the packets unmarked. The main
reason for only marking some packets is to maintain usable media reason for only marking some packets is to maintain usable media
delivery during the ECN initiation phase in those cases where ECN delivery during the ECN initiation phase in those cases where ECN
is not supported by the network path. A secondary reason to send is not supported by the network path. A secondary reason to send
some not-ECT packets are to ensure that the receivers will send some not-ECT packets are to ensure that the receivers will send
RTCP reports on this sender, even if all ECT marked packets are RTCP reports on this sender, even if all ECT marked packets are
lost in transit. The not-ECT packets also provide a base-line to lost in transit. The not-ECT packets also provide a base-line to
compare performance parameters against. An RTP sender is compare performance parameters against. A fourth reason for only
RECOMMENDED to send a minimum of two packets with ECT markings per probing with a small number of packets is to reduce the risk that
RTCP reporting interval, one with ECT(0) and one with ECT(1), and significant numbers of congestion markings might be lost if ECT is
will continue to send some ECT marked traffic as long as the ECN cleared to Not-ECT by an ECN-Reverting Meddlebox. Then any
initiation phase continues. The sender SHOULD NOT mark all RTP resulting lack of congestion response is likely to have little
packets as ECT during the ECN initiation phase. damaging affect on others. An RTP sender is RECOMMENDED to send a
minimum of two packets with ECT markings per RTCP reporting
interval, one with ECT(0) and one with ECT(1), and will continue
to send some ECT marked traffic as long as the ECN initiation
phase continues. The sender SHOULD NOT mark all RTP packets as
ECT during the ECN initiation phase.
This memo does not mandate which RTP packets are marked with ECT This memo does not mandate which RTP packets are marked with ECT
during the ECN initiation phase. An implementation should insert during the ECN initiation phase. An implementation should insert
ECT marks in RTP packets in a way that minimises the impact on ECT marks in RTP packets in a way that minimises the impact on
media quality if those packets are lost. The choice of packets to media quality if those packets are lost. The choice of packets to
mark is clearly very media dependent, but the usage of RTP NO-OP mark is clearly very media dependent, but the usage of RTP NO-OP
payloads [I-D.ietf-avt-rtp-no-op], if supported, would be an payloads [I-D.ietf-avt-rtp-no-op], if supported, would be an
appropriate choice. For audio formats, if would make sense for appropriate choice. For audio formats, if would make sense for
the sender to mark comfort noise packets or similar. For video the sender to mark comfort noise packets or similar. For video
formats, packets containing P- or B-frames, rather than I-frames, formats, packets containing P- or B-frames, rather than I-frames,
skipping to change at page 19, line 17 skipping to change at page 23, line 39
(Section 5.2). Reception of subsequent ECN-CE marked packets (Section 5.2). Reception of subsequent ECN-CE marked packets
SHOULD result in additional early or immediate ECN feedback SHOULD result in additional early or immediate ECN feedback
packets being sent. packets being sent.
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 6.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
report indicating successful receipt of the ECT-marked packets, report indicating successful receipt of the ECT-marked packets,
with no negative indications, from a single RTP receiver. After with no negative indications, from a single RTP receiver. After
declaring provisional success, the sender MAY generate ECT-marked declaring provisional success, the sender MAY generate ECT-marked
packets as described in Section 4.3, provided it continues to packets as described in Section 6.3, provided it continues to
monitor the RTCP reports for a period of three RTCP reporting monitor the RTCP reports for a period of three RTCP reporting
intervals from the time the ECN initiation started, to check if intervals from the time the ECN initiation started, to check if
there is any other participants in the session. If other there 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
skipping to change at page 20, line 20 skipping to change at page 24, line 44
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 4.3 describes the ongoing monitoring convey ECN feedback; Section 6.3 describes the ongoing monitoring
that must be performed to ensure the path continues to robustly that must be performed to ensure the path continues to robustly
support ECN. support ECN.
4.2.2. Detection of ECT using STUN with ICE When a sender or receiver detects ECN failures on paths they should
log these to enable follow up and statistics gathering regarding
broken paths. The logging mechanism used is implementation
dependent.
6.2.2. Detection of ECT using STUN with ICE
This section describes an OPTIONAL method that can be used to avoid This section describes an OPTIONAL method that can be used to avoid
media impact and also ensure an ECN capable path prior to media media impact and also ensure an ECN capable path prior to media
transmission. This method is considered in the context where the transmission. This method is considered in the context where the
session participants are using ICE [RFC5245] to find working session participants are using ICE [RFC5245] to find working
connectivity. We need to use ICE rather than STUN only, as the connectivity. We need to use ICE rather than STUN only, as the
verification needs to happen from the media sender to the address and verification needs to happen from the media sender to the address and
port on which the receiver is listening. port on which the receiver is listening.
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, an additional connectivity check candidate is not a relayed address, an additional connectivity check
is performed, sending the "ECT Check" attribute in a STUN packet that is performed, sending the "ECT Check" attribute in a STUN packet that
is ECT marked. On reception of the packet, the STUN server will note is ECT marked. On reception of the packet, a STUN server supporting
the received ECN field value, and send a STUN/UDP/IP packet in reply, this extension will note the received ECN field value, and send a
with the ECN field set to not-ECT, and including an ECN check STUN/UDP/IP packet in reply, with the ECN field set to not-ECT, and
attribute. including an ECN check attribute. A STUN server that doesn't
understand the extension or are incapable of reading the ECN values
on incomming STUN packets SHALL follow the STUN specifications rule
for unknown comprehension-required attributes, i.e. send a 420
(Unknown Attribute) response back.
The STUN ECN check attribute contains one field and a flag. The flag The STUN ECN check attribute contains one field and a flag. The flag
indicates if the echo field contains a valid value or not. The field indicates if the echo field contains a valid value or not. The field
is the ECN echo field, and when valid contains the two ECN bits from is the ECN echo field, and when valid contains the two ECN bits from
the packet it echoes back. The ECN check attribute is a 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 3: ECN Check STUN Attribute
V: Valid (1 bit) ECN Echo value field is valid when set to 1, and V: Valid (1 bit) ECN Echo value field is valid when set to 1, and
invalid when set 0. invalid when set 0.
ECF: ECN Echo value field (2 bits) contains the ECN field value of ECF: ECN Echo value field (2 bits) contains the ECN field value of
the STUN packet it echoes back when field is valid. If invalid the STUN packet it echoes back when field is valid. If invalid
the content is arbitrary. the content is arbitrary.
Reserved: Reserved bits (29 bits) SHOULD be set to 0 on Reserved: Reserved bits (29 bits) SHALL be set to 0 on transmission,
transmission, and SHALL be ignored on reception. 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
packet the request was received in. Upon forming the response the packet the request was received in. Upon forming the response the
server SHALL include the ECN Check attribute setting the V bit to server SHALL include the ECN Check attribute setting the V bit to
valid and include the read value of the ECN field into the ECF field. valid and include the read value of the ECN field into the ECF field.
If the STUN responder was unable to assertain due to temporary errors
the ECN value of the STUN request, it SHALL set the V bit in the
response to 0. The STUN client may retry immediately.
4.2.3. Leap of Faith ECT initiation method 6.2.3. Leap of Faith ECT initiation method
This method for initiating ECN usage is a leap of faith that assumes This method for initiating ECN usage is a leap of faith that assumes
that ECN will work on the used path(s). It is not generally that ECN will work on the used path(s). The method is to go directly
recommended as the impact on both the application and the network may to "ongoing use of ECN" as defined in Section 6.3. Thus all RTP
be substantial if the path is not ECN capable. Applications may packets MAY be marked as ECT and the failure detection MUST be used
experience high packet loss rates, this is both from dropped ECT to detect any case when the assumption that the path was ECT capable
marked packets, and as a result of driving the network into higher is wrong. This method is only recommended for controlled
degrees of congestion by not being responsive to ECN marks. The environments where the whole path(s) between sender and receiver(s)
network may experience higher degrees of congestion due to the has been built and verified to be ECT.
unresponsiveness of the sender due to lost ECN-CE marks from non-
compliant re-marking.
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
failure detection MUST be used to detect any case when the assumption
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 an ECN-blocking middlebox, then receivers downstream of
receiver downstream of that middlebox will not receive any RTP data that middlebox will not receive any RTP data packets from the sender,
packets from that sender, and hence will not consider it to be an and hence will not consider it to be an active RTP SSRC. The sender
active RTP SSRC. The sender can detect this, since SR/RR packets can detect this and revert to sending packets without ECT marks,
from such receivers will either not include a report for the sender's since RTCP SR/RR packets from such receivers will either not include
SSRC, or will include a report claiming that no packets have been a report for sender's SSRC, or will report that no packets have been
received. The sender should be aware that a receiver may generate received, but this takes at least one RTCP reporting interval. It
its first RTCP packet immediately on joining a unicast session, or should be noted that a receiver might generate its first RTCP packet
very shortly after joining a RTP/AVPF session, before it has had immediately on joining a unicast session, or very shortly after
chance to receive any data packets. A sender that receives RTCP joining a RTP/AVPF session, before it has had chance to receive any
SR/RR packet indicating lack of reception by a receiver may therefore data packets. A sender that receives RTCP SR/RR packet indicating
have to wait for a second RTCP report from that receiver to be sure lack of reception by a receiver SHOULD therefore wait for a second
that the lack of reception is due to ECT-marking. RTCP report from that receiver to be sure that the lack of reception
is due to ECT-marking. Since this recovery process can take several
This method is only recommended for controlled environments where the tens of seconds, during which time the RTP session is unusable for
whole path(s) between sender and receiver(s) has been built and media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation
verified to be ECT. It is NOT RECOMMENDED that the leap-of-faith ECT method be used in environments where ECN-blocking middleboxes are
initiation method is used on unmanaged public Internet paths. likely to be present.
4.2.4. ECN Nonce during initiation
If the ECN Nonce was enabled in the signalling, it SHALL be used
during the initiation phase as described in Section 4.3.2.1.
4.3. Ongoing Use of ECN Within an RTP Session 6.3. Ongoing Use of ECN Within an RTP Session
Once ECN usage has been successfully initiated for an RTP sender, Once ECN usage has been successfully initiated for an RTP sender,
that sender begins sending all RTP data packets as ECT-marked, and that sender begins sending all RTP data packets as ECT-marked, and
its receivers continue sending ECN feedback information via RTCP its receivers continue sending ECN feedback information via RTCP
packets. This section describes procedures for sending ECT-marked packets. This section describes procedures for sending ECT-marked
data, providing ECN feedback information via RTCP, responding to ECN data, providing ECN feedback information via RTCP, responding to ECN
feedback information, and detecting failures and misbehaving feedback information, and detecting failures and misbehaving
receivers. receivers.
4.3.1. Transmission of ECT-marked RTP Packets 6.3.1. Transmission of ECT-marked RTP Packets
After a sender has successfully initiated ECN usage, it SHOULD mark After a sender has successfully initiated ECN usage, it SHOULD mark
all the RTP data packets it sends as ECT. The sender SHOULD mark all the RTP data packets it sends as ECT. The sender SHOULD mark
packets as ECT(0) unless the receiver expresses a preference for packets as ECT(0) unless the receiver expresses a preference for
ECT(1) or random choice using the "ect" parameter in the "a=ecn- ECT(1) using the "ect" parameter in the "a=ecn-capable-rtp"
capable-rtp" attribute; or unless the ECN nonce is in use, in which attribute.
case random ECT marks MUST be used. If the sender selects a random
choice of ECT marking, the sender MUST record the statistics for the
different ECN values sent. If ECN nonce is activated the sender must
record the value and calculate the ECN-nonce sum for outgoing packets
[RFC3540] to allow the use of the ECN-nonce to detect receiver
misbehaviour (see Section 4.4). Guidelines on the random choice of
ECT values are provided in Section 8 of [RFC3540].
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. For control packets there might be exceptions,
like the STUN based ECN check defined in Section 6.2.2.
4.3.2. Reporting ECN Feedback via RTCP 6.3.2. Reporting ECN Feedback via RTCP
An RTP receiver that receives a packet with an ECN-CE mark, or that An RTP receiver that receives a packet with an ECN-CE mark, or that
detects a packet loss, MUST schedule the transmission of an RTCP ECN detects a packet loss, MUST schedule the transmission of an RTCP ECN
feedback packet as soon as possible (subject to the constraints of feedback packet as soon as possible (subject to the constraints of
[RFC4585] and [RFC3550]) to report this back to the sender. The [RFC4585] and [RFC3550]) to report this back to the sender. There
feedback RTCP packet sent SHALL consist of at least one ECN feedback should be no difference in behavior if ECN-CE marks or packet drops
packet (Section 5) reporting on the packets received since the last are detected. The feedback RTCP packet sent SHALL consist of at
ECN feedback packet, and SHOULD contain an RTCP SR or RR packet. The least one ECN feedback packet (Section 5) reporting on the packets
RTP/AVPF profile in early or immediate feedback mode SHOULD be used received since the last ECN feedback packet, and SHOULD contain an
where possible, to reduce the interval before feedback can be sent. RTCP SR or RR packet. The RTP/AVPF profile in early or immediate
To reduce the size of the feedback message, reduced size RTCP feedback mode SHOULD be used where possible, to reduce the interval
[RFC5506] MAY be used if supported by the end-points. Both RTP/AVPF before feedback can be sent. To reduce the size of the feedback
and reduced size RTCP MUST be negotiated in the session set-up message, reduced size RTCP [RFC5506] MAY be used if supported by the
signalling before they can be used. ECN Nonce information SHOULD NOT end-points. Both RTP/AVPF and reduced size RTCP MUST be negotiated
be included in early or immediate reports, only when regular reports in the session set-up signalling before they can be used.
are sent.
Every time a regular compound RTCP packet is to be transmitted, an Every time a regular compound RTCP packet is to be transmitted, an
ECN-capable RTP receiver MUST include an RTCP XR ECN summary report ECN-capable RTP receiver MUST include an RTCP XR ECN summary report
as described in Section 5.2 as part of the compound packet. If ECN- as described in Section 5.2 as part of the compound packet.
nonce is enabled the receiver MUST also include an RTCP XR Nonce
report packet as described in Section 5.3. It is important to
configure the RTCP bandwidth (e.g. using an SDP "b=" line) such that
the bit-rate is sufficient for a usage that includes these regular
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.
skipping to change at page 24, line 11 skipping to change at page 28, line 24
overhead for group communication using ECN. overhead for group communication using ECN.
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 6.2.1.
4.3.2.1. ECN Nonce Reporting
When ECN Nonce reporting is used, it requires both the ECN nonce sum
and the sequence numbers for packets where the ECN marking has been
lost to be reported. This information is variable size as it depends
on both the total number of packet sent per reporting interval and
the CE and Packet loss pattern how many bits are required for
reporting.
The RTCP packets may be lost, and to avoid the possibility for
cheating by "losing" the Nonce information for where one is cheating
the nonce coverage needs to be basically complete. Thus the Nonce
reporting SHOULD cover at least the 3 regular reporting intervals.
The only exception allowed is if the reporting information becomes
too heavy and makes the RTCP report packet become larger than the
MTU. In that case a receiver MAY reduce the coverage for the ECN
nonce to only the last or two last reporting intervals. A sender
should consider the received size report for cases where the coverage
is not at least three reporting intervals and determine if this may
be done to cheat or not. Failure to have reported on all intervals
MAY be punished by reducing the congestion safe rate.
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
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
interval is explicitly signalled in the RTCP XR Nonce report packet.
The initial value for the Nonce is 00b.
4.3.3. Response to Congestion Notifications 6.3.3. Response to Congestion Notifications
When RTP packets are received with ECN-CE marks, the sender and/or When RTP packets are received with ECN-CE marks, the sender and/or
receivers MUST react with congestion control as-if those packets had receivers MUST react with congestion control as-if those packets had
been lost. Depending on the media format, type of session, and RTP been lost. Depending on the media format, type of session, and RTP
topology used, there are several different types of congestion topology used, there are several different types of congestion
control that can be used. control that can be used.
Sender-Driven Congestion Control: The sender may be responsible for Sender-Driven Congestion Control: The sender may be responsible for
adapting the transmitted bit-rate in response to RTCP ECN adapting the transmitted bit-rate in response to RTCP ECN
feedback. When the sender receives the ECN feedback data it feeds feedback. When the sender receives the ECN feedback data it feeds
skipping to change at page 26, line 13 skipping to change at page 29, line 43
We note that ECN support is not a silver bullet to improving We note that ECN support is not a silver bullet to improving
performance. The use of ECN gives the chance to respond to performance. The use of ECN gives the chance to respond to
congestion before packets are dropped in the network, improving the congestion before packets are dropped in the network, improving the
user experience by allowing the RTP application to control how the user experience by allowing the RTP application to control how the
quality is reduced. An application which ignores ECN congestion quality is reduced. An application which ignores ECN congestion
experienced feedback is not immune to congestion: the network will experienced feedback is not immune to congestion: the network will
eventually begin to discard packets if traffic doesn't respond. It eventually begin to discard packets if traffic doesn't respond. It
is in the best interest of an application to respond to ECN is in the best interest of an application to respond to ECN
congestion feedback promptly, to avoid packet loss. congestion feedback promptly, to avoid packet loss.
4.4. Detecting Failures and Receiver Misbehaviour 6.4. Detecting Failures
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
endpoint (server) acts on behalf of the network.
The assumption about the senders acting on the behalf of the network Senders and receivers can deliberately ignore ECN-CE and thus get a
may be reduced due to the nature of peer-to-peer use of RTP. Still a benefit over behaving flows (cheating). Nonce [RFC3540] is an
significant portion of RTP senders are infrastructure devices (for addition to TCP that solves this issue as long as the sender acts on
example, streaming media servers) that do have an interest in behalf of the network. The assumption about the senders acting on
protecting both service quality and the network. In addition, as the behalf of the network may be reduced due to the nature of peer-
real-time media is commonly sensitive to increased delay and packet to-peer use of RTP. Still a significant portion of RTP senders are
loss, it will be in both media sender and receivers interest to infrastructure devices (for example, streaming media servers) that do
minimise the number and duration of any congestion events as they have an interest in protecting both service quality and the network.
will affect media quality. Even though there may be cases where nonce can be applicable also for
RTP, it is not included in this specification. It is however worth
mention that, as real-time media is commonly sensitive to increased
delay and packet loss, it will be in both media sender and receivers
interest to minimise the number and duration of any congestion events
as they 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 re-mark a packet from ECT to not-ECT. That The other action is to re-mark a packet from ECT or CE to not-ECT.
has less dire results, however, it should be detected so that ECN That has less dire results, however, it should be detected so that
usage can be suspended to prevent misusing the network. ECN 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 unless their is duplication in the network. If this
reasons, a translator changing the stream or not carrying the ECN number doesn't agree there are two likely reasons, a translator
markings forward, or that some node re-marks the packets. In both changing the stream or not carrying the ECN markings forward, or that
cases the usage of ECN is broken on the path. By tracking all the some node re-marks the packets. In both cases the usage of ECN is
different possible ECN field values a sender can quickly detect if broken on the path. By tracking all the different possible ECN field
some non-compliant behavior is happing on the path. values a sender can quickly detect if some non-compliant behavior is
happing on the path.
Thus packet losses and non-matching ECN field value statistics are Thus packet losses and non-matching ECN field value statistics are
possible indication of issues with using ECN over the path. The next possible indication of issues with using ECN over the path. The next
section defines both sender and receiver reactions to these cases. section defines both sender and receiver reactions to these cases.
4.4.1. Fallback mechanisms 6.4.1. Fallback mechanisms
Upon the detection of a potential failure both the sender and the Upon the detection of a potential failure both the sender and the
receiver can react to mitigate the situation. receiver can react to mitigate the situation.
A receiver that detects a packet loss burst MAY schedule an early A receiver that detects a packet loss burst MAY schedule an early
feedback packet to report this to the sender that includes at least feedback packet to report this to the sender that includes at least
the RTCP RR and the ECN feedback message. Thus speeding up the the RTCP RR and the ECN feedback message. Thus speeding up the
detection at the sender of the losses and thus triggering sender side detection at the sender of the losses and thus triggering sender side
mitigation. mitigation.
skipping to change at page 27, line 46 skipping to change at page 31, line 30
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. It is
however appropriate to mention that there are also issues such as re-
routing of traffic due to a flappy route table or ecxessive
reordering and other issues that are not directly ECN related but
nevertheless cause problems in receivers.
4.4.2. Interpretation of ECN Summary information 6.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 29, line 12 skipping to change at page 32, line 51
Detecting clearing of ECN field: If the ratio between ECT and not-ECT Detecting clearing of ECN field: If the ratio between ECT and not-ECT
transmitted in the reports has become all not-ECT or substantially transmitted in the reports has become all not-ECT or substantially
changed towards not-ECT then this is clearly indication that the path changed towards not-ECT then this is clearly indication that the path
results in clearing of the ECT field. results in clearing of the ECT field.
Dropping of ECT packets: To determine if the packet drop ratio is Dropping of ECT packets: To determine if the packet drop ratio is
different between not-ECT and ECT marked transmission requires a mix different between not-ECT and ECT marked transmission requires a mix
of transmitted traffic. The sender should compare if the delivery of transmitted traffic. The sender should compare if the delivery
percentage (delivered / transmitted) between ECT and not-ECT is percentage (delivered / transmitted) between ECT and not-ECT is
significantly different. Care must be taken if the number of packets significantly different. Care must be taken if the number of packets
are low in either of the categories. are low in either of the categories. One must also take into account
the level of CE marking. A CE marked packet would have been dropped
4.4.3. Using ECN-nonce unless it was ECT marked. Thus, the packet loss level for not-ECT
should be aprroximately equal to the loss rate for ECT when counting
This document offers ECN Nonce as a method of strengthening the the CE marked packets as lost ones. A sender performing this
detection of failures, and to allow senders to verify the receiver calculation needs to ensure that the difference is statistcally
behavior. We note that it appears counter-productive for a receiver significant.
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
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
use repair mechanisms as FEC or retransmission may consider the usage
of the ECN nonce to prevent cheating.
5. RTCP Extensions for ECN feedback
This documents defines three different RTCP extensions: one RTCP AVPF
NACK Transport feedback format for urgent ECN information; one RTCP
XR ECN summary report block type for regular reporting of the ECN
marking information; and one additional RTCP XR report block type for
ECN nonce.
5.1. ECN Feedback packet
This AVPF NACK feedback format is intended for usage in AVPF early or
immediate feedback modes when information needs to urgently reach the
sender. Thus its main use is to report on reception of an ECN-CE
marked RTP packet so that the sender may perform congestion control,
or to speed up the initiation procedures by rapidly reporting that
the path can support ECN-marked traffic. The feedback format is also
defined with reduced size RTCP [RFC5506] in mind, where RTCP feedback
packets may be sent without accompanying Sender or Receiver Reports
that would contain the Extended Highest Sequence number and the
accumulated number of packet losses. Both are important for ECN to
verify functionality and keep track of when CE marking does occur.
The RTCP AVPF NACK packet starts with the common header defined by
the RTP/AVPF profile [RFC4585] which is reproduced here for the
reader's information:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
Figure 2: AVPF Feedback common header
From Figure 2 it can be determined the identity of the feedback
provider and for which RTP packet sender it applies. Below is the
feedback information format defined that is inserted as FCI for this
particular feedback messages that is identified with an FMT
value=[TBA1].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Highest Sequence Number | Lost packets counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter | ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ECN Feedback Format
The FCI information for the ECN Feedback format (Figure 3) are the
following:
Extended Highest Sequence Number: The least significant 20-bit from
an Extended highest sequence number received value as defined by
[RFC3550]. Used to indicate for which packet this report is valid
upto.
Lost Packets Counter: The cumulative number of RTP packets that the
receiver expected to receive from this SSRC, minus the number of
packets it actually received. This is the same as the cumulative
number of packets lost defined in Section 6.4.1 of [RFC3550]
except represented in 12-bit signed format, compared to 24-bit in
RTCP SR or RR packets. As with the equivalent value in RTCP SR or
RR packets, note that packets that arrive late are not counted as
lost, and the loss may be negative if there are duplicates.
CE Counter: The cumulative number of RTP packets received from this
SSRC since the receiver joined the RTP session that were ECN-CE
marked. The receiver should keep track of this value using a
local representation that is longer than 16-bits, and only include
the 16-bits with least significance. In other words, the field
will wrap to 0 if more than 65535 packets has been received.
ECT(0) Counter: The cumulative number of RTP packets received from
this SSRC since the receiver joined the RTP session that had an
ECN field value of ECT(0). The receiver should keep track of this
value using a local representation that is longer than 16-bits,
and only include the 16-bits with least significance. In other
words, the field will wrap if more than 65535 packets have been
received.
ECT(1) Counter: The cumulative number of RTP packets received from
this SSRC since the receiver joined the RTP session that had an
ECN field value of ECT(1). The receiver should keep track of this
value using a local representation that is longer than 16-bits,
and only include the 16-bits with least significance. In other
words, the field will wrap if more than 65535 packets have been
received.
not-ECT Counter: The cumulative number of RTP packets received from
this SSRC since the receiver joined the RTP session that had an
ECN field value of not-ECT. The receiver should keep track of
this value using a local representation that is longer than 16-
bits, and only include the 16-bits with least significance. In
other words, the field will wrap if more than 65535 packets have
been received.
Each FCI block reports on a single source (SSRC). Multiple sources
can be reported by including multiple RTCP feedback messages in an
compound RTCP packet. The AVPF common header indicates both the
sender of the feedback message and on which stream it relates to.
The Counters SHALL be initiated to 0 for a new receiver. This to
enable detection of CE or Packet loss already on the initial report
from a specific participant.
The Extended Highest sequence number and packet loss fields are both
truncated in comparison to the RTCP SR or RR versions. This is to
save bits as the representation is redundant unless reduced size RTCP
is used in such a way that only feedback packets are transmitted,
with no SR or RR in the compound RTCP packet. Due to that regular
RTCP reporting will include the longer versions of the fields the
wrapping issue will be less unless the packet rate of the application
is so high that the fields will wrap within a regular RTCP reporting
interval. In those case the feedback packet need to be sent in a
compound packet together with the SR or RR packet.
There is an issue with packet duplication in relation to the packet
loss counter. If one avoids holding state for which sequence number
has been received then the way one can count loss is to count the
number of received packets and compare that to the number of packets
expected. As a result a packet duplication can hide a packet loss.
If a receiver is tracking the sequence numbers actually received and
suppresses duplicates it provides for a more reliable packet loss
indication. Reordering may also result in that packet loss is
reported in one report and then removed in the next.
The CE counter is actually more robust for packet duplication.
Adding each received CE marked packet to the counter is not an issue.
If one of the clones was CE marked that is still a indication of
congestion. Packet duplication has potential impact on the ECN
verification. Thus the sum of packets reported may be higher than
the number sent. However, most detections are still applicable.
5.2. RTCP XR Report block for ECN summary information
This report block combined with RTCP SR or RR report blocks carries
the same information as the ECN Feedback Packet and shall be based on
the same underlying information. However, there is a difference in
semantics between the feedback format and this XR version. Where the
feedback format is intended to report on a CE mark as soon as
possible, this extended report is for the regular RTCP report and
continuous verification of the ECN functionality end-to-end.
The ECN Summary report block consists of one report block header:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
and then followed of one or more of the following report data blocks:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter | ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BT: Block Type identifying the ECN summary report block. Value is
[TBA2].
Reserved: All bits SHALL be set to 0 on transmission and ignored on
reception.
Block Length: The length of the report block. Used to indicate the
number of report data blocks present in the ECN summary report.
This length will always equal 3, since blocks are a fixed size.
SSRC of Media Sender: The SSRC identifying the media sender this
report is for.
CE Counter: as in Section 5.1.
ECT(0) Counter: as in Section 5.1.
ECT(1) Counter: as in Section 5.1.
not-ECT Counter: as in Section 5.1.
The Extended Highest Sequence number and the packet loss counter for
each SSRC is not present in RTCP XR report, in contrast to the
feedback version. The reason is that this summary report will always
be sent in a RTCP compound packet where the Extended Highest Sequence
number and the accumulated number of packet losses are present in the
RTCP Sender Report or Receiver Report packet's report block.
5.3. RTCP XR Report Block for ECN Nonce
This RTCP XR block is for ECN Nonce reporting. It consists of an
initial part that contains the ECN nonce XOR sum, followed by a
series of bit-vector chunks that indicate which RTP sequence numbers
were lost or CE-marked, and so weren't included in the ECN nonce sum.
The bit-vector uses 1 to indicate that the packet wasn't included in
the ECN nonce sum and 0 for packets that where.
The bit-vector is expressed using either Run-Length Encoding or 15-
bit explicit bit-vectors. The whole vector is encoded using the 16-
bit chunks as defined by Section 4.1.1, 4.1.2, and 4.1.3 in
[RFC3611]. The Terminating Null Chunk MUST be used as padding in
cases the total number of chunks would otherwise be odd and thus the
report block wouldn't reach a 32-bit boundary.
The ECN Nonce report block structure is the following:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BT |R|R|R|R|INV|RNV| Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Begin_seq | End_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
BT: Block Type, the value identifying this block is [TBA3].
R: Bits are reserved and MUST be set to 0 on transmission and MUST be
ignored on reception.
Block Length: The block length of this full report block in 32-bit
words minus one. The minimal report block size is 3, i.e. fixed
parts (12 bytes) plus 2 chunks (4 bytes) expressed as 32-bit words
(3+1) minus 1.
SSRC of Media Sender SSRC of Media Sender that this report concerns
INV: Initial Nonce Value. Which is the value of Nonce prior to the
XOR addition of the ECN field value for the packet that start the
nonce reporting interval. This first included sequence number is
given by the "begin_seq" value. This to allow running
calculations and only need to save nonce values at reporting
boundaries.
RNV: Resulting Nonce Value. The Nonce sum value resulting after
having XOR the ECN field value for all packets received and not
ECN-CE marked with the INV value up to the packet indicated by the
"end_seq" sequence number value.
begin_seq: First Sequence number this report covers.
end_seq: Last RTP sequence number included in this report.
chunk i: A chunk reporting on a part of bit-vector indicating if the
packet was excluded from the ECN Nonce due to being lost or ECN CE
marked.
The Nonce sum initial value for a new media sender (new SSRC) SHALL
be 00b. Otherwise the Initial value is the Nonce value calculated
for the RTP packet with sequence number begin_seq -1. The initial
value for the expressed reporting interval is included in the INV
field. The receiver calculates the 2-bit Nonce XOR sum over all
received RTP packets in the reporting interval including the one with
end_seq sequence number. We note that the RTCP participant doing the
Nonce sum MUST perform suppression of packet duplicates. The nonce
sum will become incorrect if any duplicates are included in the sum.
All packets not received or received as ECN-CE marked when
constructing the ECN Nonce report MUST be explicitly marked in the
bitvector.
The Nonce reporting interval is RECOMMENDED to cover all the RTP
packets received during the three last regular reporting intervals.
This is to ensure that the sender will receive a report over all RTP
packets. Failure to deliver reports that cover all the packets may
be interpreted as an attempt to cheat.
Two additional considerations must be made when selecting the
reporting interval. First, are the MTU considerations. The packet
vector and its encoding into chunks results in a variable sized
report. The size depends on two main factors, the number of packets
to report on and the frequency of bit-value changes in the vector.
The reporting interval may need to be shortened to two or even one
reporting interval if the resulting ECN nonce report becomes too big
to fit into the RTCP packet.
Secondly, the RTP sequence number can easily wrap and that needs to
be considered when they are handled. The report SHALL NOT report on
more than 32768 consecutive packets. The last sequence number is the
extended sequence number that is equal too or smaller (less than
65535 packets) than the value present in the Receiver Reports
"extended highest sequence number received" field. The "first
sequence number" value is thus an extended sequence number which is
smaller than the "last sequence number". If there is a wrap between
the first sequence number and the last, i.e. if the first sequence
number is greater than the last sequence number (when seen as 16-bit
unsigned integers), this needs to included in the calculation. If an
application is having these issues, the frequency of the regular RTCP
reporting should be modified by ensuring that the application chooses
appropriate settings for the minimum RTCP reporting interval
parameters.
Both the ECN-CE and packet loss information is structured as bit
vectors where the first bit represents the RTP packet with the
sequence number equal to the First Sequence number. The bit-vector
will contain values representing all packets up to and including the
one in the "end_seq" field. The chunk mechanism used to represent
the bit-vector in an efficient way may appear longer upon reception
if an explicit bit-vector is used as the last chunk. Bit-values
representing packets with higher sequence number (modulo 16) than
"end_seq" are not valid and SHALL be ignored.
The produced bit-vector is encoded using chunks. The chunks are any If erronous behavior is detected, it should be logged to enable
of the three types defined in [RFC3611], Run Length Chunk (Section follow up and statistics gathering.
4.1.1 of [RFC3611]), Bit Vector Chunk (Section 4.1.2 of [RFC3611]),
or Terminating Null Chunk (Section 4.1.3 of [RFC3611]). Where the
Terminating Null Chunk may only appear as the last chunk, and only in
cases where the number of chunks otherwise would be odd.
6. Processing RTCP ECN Feedback in RTP Translators and Mixers 7. 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. This includes both downstream RTCP
reports generated by the media sender, and also reports generated by
the receivers, flowing upstream back towards the sender.
6.1. Fragmentation and Reassembly in Translators 7.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, and without reference to the congestion changing the media encoding, and without reference to the congestion
state of the networks it bridges. An example of this might be to state of the networks it bridges. An example of this might be to
combine packets of a voice-over-IP stream coded with one 20ms frame combine packets of a voice-over-IP stream coded with one 20ms frame
per RTP packet into new RTP packets with two 20ms frames per packet, per RTP packet into new RTP packets with two 20ms frames per packet,
thereby reducing the header overheads and so stream bandwidth, at the thereby reducing the header overheads and so stream bandwidth, at the
expense of an increase in latency. If multiple data packets are re- expense of an increase in latency. If multiple data packets are re-
encoded into one, or vice versa, the RTP translator MUST assign new encoded into one, or vice versa, the RTP translator MUST assign new
sequence numbers to the outgoing packets. Losses in the incoming RTP sequence numbers to the outgoing packets. Losses in the incoming RTP
skipping to change at page 37, line 5 skipping to change at page 33, line 50
RTCP ECN feedback packets (Section 5.1) contain six fields that are RTCP ECN feedback packets (Section 5.1) contain six fields that are
rewritten in an RTP translator that fragments or reassembles packets: rewritten in an RTP translator that fragments or reassembles packets:
the extended highest sequence number, the lost packets counter, the the extended highest sequence number, the lost packets counter, the
CE counter, and not-ECT counter, the ECT(0) counter, and the ECT(1) CE counter, and not-ECT counter, the ECT(0) counter, and the ECT(1)
counter. The RTCP XR report block for ECN summary information counter. The RTCP XR report block for ECN summary information
(Section 5.2) includes a subset of these fields excluding the (Section 5.2) includes a subset of these fields excluding the
extended highest sequence number and lost packets counter. The extended highest sequence number and lost packets counter. The
procedures for rewriting these fields are the same for both types of procedures for rewriting these fields are the same for both types of
RTCP ECN feedback packet. RTCP ECN feedback packet.
When receiving an RTCP ECN feedback packet, an RTP translator first When receiving an RTCP ECN feedback packet for the translated stream,
determines the range of packets to which the report corresponds. The an RTP translator first determines the range of packets to which the
extended highest sequence number in the RTCP ECN feedback packet (or report corresponds. The extended highest sequence number in the RTCP
in the RTCP SR/RR packet contained within the compound packet, in the ECN feedback packet (or in the RTCP SR/RR packet contained within the
case of RTCP XR ECN summary reports) specifies the end sequence compound packet, in the case of RTCP XR ECN summary reports)
number of the range. For the first RTCP ECN feedback packet specifies the end sequence number of the range. For the first RTCP
received, the initial extended sequence number of the range may be ECN feedback packet received, the initial extended sequence number of
determined by subtracting the sum of the lost packets counter, the CE the range may be determined by subtracting the sum of the lost
counter, the not-ECT counter, the ECT(0) counter and the ECT(1) packets counter, the CE counter, the not-ECT counter, the ECT(0)
counter from the extended highest sequence number (this will be counter and the ECT(1) counter from the extended highest sequence
inaccurate if there is packet duplication). For subsequent RTCP ECN number (this will be inaccurate if there is packet duplication). For
feedback packets, the starting sequence number may be determined as subsequent RTCP ECN feedback packets, the starting sequence number
being one after the extended highest sequence number of the previous may be determined as being one after the extended highest sequence
RTCP ECN feedback packet received from the same SSRC. These values number of the previous RTCP ECN feedback packet received from the
are in the sequence number space of the translated packets. same SSRC. These values are in the sequence number space of the
translated packets.
Based on its knowledge of the translation process, the translator Based on its knowledge of the translation process, the translator
determines the sequence number range for the corresponding original, determines the sequence number range for the corresponding original,
pre-translation, packets. The extended highest sequence number in pre-translation, packets. The extended highest sequence number in
the RTCP ECN feedback packet is rewritten to match the final sequence the RTCP ECN feedback packet is rewritten to match the final sequence
number in the pre-translation sequence number range. number in the pre-translation sequence number range.
The translator then determines the ratio, R, of the number of packets The translator then determines the ratio, R, of the number of packets
in the translated sequence number space (numTrans) to the number of in the translated sequence number space (numTrans) to the number of
packets in the pre-translation sequence number space (numOrig) such packets in the pre-translation sequence number space (numOrig) such
skipping to change at page 38, line 21 skipping to change at page 35, line 21
likely to be a reasonable assumption in the type of environment where likely to be a reasonable assumption in the type of environment where
RTP translators that fragment or reassemble packets are deployed, as RTP translators that fragment or reassemble packets are deployed, as
their entire purpose is to change the number of packets being sent to their entire purpose is to change the number of packets being sent to
adapt to known limitations of the network, but is not necessarily adapt to known limitations of the network, but is not necessarily
valid in general. valid in general.
The rewritten RTCP ECN feedback report is sent from the other side of The rewritten RTCP ECN feedback report is sent from the other side of
the translator to that which it arrived (as part of a compound RTCP the translator to that which it arrived (as part of a compound RTCP
packet containing other translated RTCP packets, where appropriate). packet containing other translated RTCP packets, where appropriate).
The RTCP XR Report Block for the ECN nonce is used to convey the ECN 7.2. Generating RTCP ECN Feedback in Media Transcoders
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.
An RTP translator acting as a media transcoder in this manner does 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 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 the RTP layer. RTCP ECN feedback packets and RTCP XR report blocks
ECN summary information, and RTCP XR report blocks for the ECN nonce for ECN summary information that are received from downstream relate
that are received from downstream relate to the translated stream, to the translated stream, and so must be processed by the translator
and so must be processed by the translator as if it were the original as if it were the original media source. These reports drive the
media source. These reports drive the congestion control loop and congestion control loop and media adaptation between the translator
media adaptation between the translator and the downstream receiver. and the downstream receiver. If there are multiple downstream
If there are multiple downstream receivers, a logically separate receivers, a logically separate transcoder instance must be used for
transcoder instance must be used for each receiver, and must process each receiver, and must process RTCP ECN feedback and summary reports
RTCP ECN feedback and summary reports independently to the other independently to the other transcoder instances. An RTP translator
transcoder instances. An RTP translator acting as a media transcoder acting as a media transcoder in this manner MUST NOT forward RTCP ECN
in this manner MUST NOT forward RTCP ECN feedback packets, RTCP XR feedback packets or RTCP XR ECN summary reports from downstream
ECN summary reports, or RTCP XR ECN nonce reports from downstream
receivers in the upstream direction. receivers in the upstream direction.
An RTP translator acting as a media transcoder will generate RTCP An RTP translator acting as a media transcoder will generate RTCP
reports upstream towards the original media sender, based on the reports upstream towards the original media sender, based on the
reception quality of the original media stream at the translator. reception quality of the original media stream at the translator.
The translator will run a separate congestion control loop and media The translator will run a separate congestion control loop and media
adaptation between itself and the media sender for each of its adaptation between itself and the media sender for each of its
downstream receivers, and must generate RTCP ECN feedback packets and downstream receivers, and must generate RTCP ECN feedback packets and
RTCP XR ECN summary reports (and RTCP XR ECN nonce reports, if RTCP XR ECN summary reports for that congestion control loop using
desired) for that congestion control loop using the SSRC of that the SSRC of that downstream receiver.
downstream receiver.
6.3. Generating RTCP ECN Feedback in Mixers 7.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. A mixer has its own SSRC, and is visible to other separate RTP flow. A mixer has its own SSRC, and is visible to other
participants in the session at the RTP layer. participants in the session at the RTP layer.
An ECN-aware RTP mixer must generate RTCP ECN feedback packets and An ECN-aware RTP mixer must generate RTCP ECN feedback packets and
RTCP XR report blocks for ECN summary information relating to the RTP RTCP XR report blocks for ECN summary information relating to the RTP
flows it terminates, in exactly the same way it would if it were an flows it terminates, in exactly the same way it would if it were an
RTP receiver. An ECN-aware RTP mixer can optionally generate RTCP XR RTP receiver. These reports form part of the congestion control loop
report blocks containing ECN nonce information. These reports form between the mixer and the media senders generating the streams it is
part of the congestion control loop between the mixer and the media mixing. A separate control loop runs between each sender and the
senders generating the streams it is mixing. A separate control loop mixer.
runs between each sender and the mixer.
An ECN-aware RTP mixer will negotiate and initiate the use of ECN on An ECN-aware RTP mixer will negotiate and initiate the use of ECN on
the mixed flows it generates, and will accept and process RTCP ECN the mixed flows it generates, and will accept and process RTCP ECN
feedback reports, RTCP XR report blocks for ECN, and RTCP XR report feedback reports and RTCP XR report blocks for ECN relating to those
blocks for the ECN nonce relating to those mixed flows as if it were mixed flows as if it were a standard media sender. A congestion
a standard media sender. A congestion control loop runs between the control loop runs between the mixer and its receivers, driven in part
mixer and its receivers, driven in part by the ECN reports received. by the ECN reports received.
An RTP mixer MUST NOT forward RTCP ECN feedback packets, RTCP XR ECN An RTP mixer MUST NOT forward RTCP ECN feedback packets or RTCP XR
summary reports, or RTCP XR ECN nonce reports from downstream ECN summary reports reports from downstream receivers in the upstream
receivers in the upstream direction. direction.
7. Implementation considerations 8. 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.
8. IANA Considerations 9. IANA Considerations
Note to RFC Editor: please replace "RFC XXXX" below with the RFC Note to RFC Editor: please replace "RFC XXXX" below with the RFC
number of this memo, and remove this note. number of this memo, and remove this note.
8.1. SDP Attribute Registration 9.1. SDP Attribute Registration
Following the guidelines in [RFC4566], the IANA is requested to Following the guidelines in [RFC4566], the IANA is requested to
register one new SDP attribute: register one new SDP attribute:
o Contact name, email address and telephone number: Authors of o Contact name, email address and telephone number: Authors of
RFCXXXX RFCXXXX
o Attribute-name: ecn-capable-rtp o Attribute-name: ecn-capable-rtp
o Type of attribute: media-level o Type of attribute: media-level
o Subject to charset: no o Subject to charset: no
This attribute defines the ability to negotiate the use of ECT (ECN This attribute defines the ability to negotiate the use of ECT (ECN
capable transport). This attribute should be put in the SDP offer if capable transport). This attribute should be put in the SDP offer if
the offering party wishes to receive an ECT flow. The answering the offering party wishes to receive an ECT flow. The answering
party should include the attribute in the answer if it wish to party should include the attribute in the answer if it wish to
receive an ECT flow. If the answerer does not include the attribute receive an ECT flow. If the answerer does not include the attribute
then ECT MUST be disabled in both directions. then ECT MUST be disabled in both directions.
8.2. AVPF Transport Feedback Message 9.2. RTP/AVPF Transport Layer Feedback Message
A new RTCP Transport feedback message needs a FMT code point The IANA is requested to register one new RTP/AVPF Transport Layer
assigned. ... Feedback Message in the table of FMT values for RTPFB Payload Types
[RFC4585] as defined in Section 5.1:
8.3. RTCP XR Report blocks Name: RTCP-ECN-FB
Long name: RTCP ECN Feedback
Value: 6
Reference: RFC XXXX
Two new RTCP XR report blocks needs to be assigned block type codes. 9.3. RTCP XR Report blocks
8.4. STUN attribute The IANA is requested to register one new RTCP XR Block Type as
defined in Section 5.2:
A new STUN attribute in the Comprehension-optional range needs to be Block Type: 13
assigned... Name: ECN Summary Report
Reference: RFC XXXX
8.5. ICE Option 9.4. STUN attribute
A new STUN [RFC5389] attribute in the Comprehension-optional range
under IETF Review (0x0000 - 0x3FFF) is request to be assigned to the
STUN attribute defined in Section 6.2.2. The STUN attribute registry
can currently be found at: http://www.iana.org/assignments/
stun-parameters/stun-parameters.xhtml.
9.5. ICE Option
A new ICE option "rtp+ecn" is registered in the non-existing registry A new ICE option "rtp+ecn" is registered in the non-existing registry
which needs to be created. which needs to be created.
9. Security Considerations 10. Security Considerations
The usage of ECN with RTP over UDP as specified in this document has The usage of ECN with RTP over UDP as specified in this document has
the following known security issues that needs to be considered. the following known security issues that needs to be considered.
External threats to the RTP and RTCP traffic: External threats to the RTP and RTCP traffic:
Denial of Service affecting RTCP: For an attacker that can modify Denial of Service affecting RTCP: For an attacker that can modify
the traffic between the media sender and a receiver can achieve the traffic between the media sender and a receiver can achieve
either of two things. 1. Report a lot of packets as being either of two things. 1. Report a lot of packets as being
Congestion Experience marked, thus forcing the sender into a Congestion Experience marked, thus forcing the sender into a
skipping to change at page 42, line 27 skipping to change at page 39, line 27
receivers: receivers:
Receivers cheating A receiver may attempt to cheat and fail to Receivers cheating A receiver may attempt to cheat and fail to
report reception of ECN-CE marked packets. The benefit for a report reception of ECN-CE marked packets. The benefit for a
receiver cheating in its reporting would be to get an unfair bit- receiver cheating in its reporting would be to get an unfair bit-
rate share across the resource bottleneck. It is far from certain rate share across the resource bottleneck. It is far from certain
that a receiver would be able to get a significant larger share of that a receiver would be able to get a significant larger share of
the resources. That assumes a high enough level of aggregation the resources. That assumes a high enough level of aggregation
that there are flows to acquire shares from. The risk of cheating that there are flows to acquire shares from. The risk of cheating
is that failure to react to congestion results in packet loss and is that failure to react to congestion results in packet loss and
increased path delay. To mitigate the risk of cheating receivers increased path delay.
the solution include ECN-Nonce that makes it probabilistically
unlikely that a receiver can cheat for more than a few packets
before being found out. See [RFC3168] and [RFC3540] for more
discussion.
Receivers misbehaving: A receiver may prevent the usage of ECN in an Receivers misbehaving: A receiver may prevent the usage of ECN in an
RTP session by reporting itself as non ECN capable or simple RTP session by reporting itself as non ECN capable. Thus forcing
provide invalid ECN-nonce values. Thus forcing the sender to turn the sender to turn off usage of ECN. In a point-to-point scenario
off usage of ECN. In a point-to-point scenario there is little there is little incentive to do this as it will only affect the
incentive to do this as it will only affect the receiver. Thus receiver. Thus failing to utilise an optimisation. For multi-
failing to utilise an optimisation. For multi-party session there party session there exist some motivation why a receiver would
exist some motivation why a receiver would misbehave as it can misbehave as it can prevent also the other receivers from using
prevent also the other receivers from using ECN. As an insider ECN. As an insider into the session it is difficult to determine
into the session it is difficult to determine if a receiver is if a receiver is misbehaving or simply incapable, making it
misbehaving or simply incapable, making it basically impossible in basically impossible in the incremental deployment phase of ECN
the incremental deployment phase of ECN for RTP usage to determine for RTP usage to determine this. If additional information about
this. If additional information about the receivers and the the receivers and the network is known it might be possible to
network is known it might be possible to deduce that a receiver is deduce that a receiver is misbehaving. If it can be determined
misbehaving. If it can be determined that a receiver is that a receiver is misbehaving, the only response is to exclude it
misbehaving, the only response is to exclude it from the RTP from the RTP session and ensure that is doesn't any longer have
session and ensure that is doesn't any longer have any valid any valid security context to affect the session.
security context to affect the session.
Misbehaving Senders: The enabling of ECN gives the media packets a Misbehaving Senders: The enabling of ECN gives the media packets a
higher degree of probability to reach the receiver compared to higher degree of probability to reach the receiver compared to
not-ECT marked ones. However, this is no magic bullet and failure not-ECT marked ones on a ECN capable path. However, this is no
to react to congestion will most likely only slightly delay a magic bullet and failure to react to congestion will most likely
buffer under-run, in which its session also will experience packet only slightly delay a buffer under-run, in which its session also
loss and increased delay. There are some chance that the media will experience packet loss and increased delay. There are some
senders traffic will push other traffic out of the way without chance that the media senders traffic will push other traffic out
being effected to negatively. However, we do note that a media of the way without being effected to negatively. However, we do
sender still needs to implement congestion control functions to note that a media sender still needs to implement congestion
prevent the media from being badly affected by congestion events. control functions to prevent the media from being badly affected
Thus the misbehaving sender is getting a unfair share. This can by congestion events. Thus the misbehaving sender is getting a
only be detected and potentially prevented by network monitoring unfair share. This can only be detected and potentially prevented
and administrative entities. See Section 7 of [RFC3168] for more by network monitoring and administrative entities. See Section 7
discussion of this issue. of [RFC3168] for more discussion of this issue.
ECN as covert channel: As the ECN fields two bits can be set to two
different values for ECT, it is possible to use ECN as a covert
channel with a possible bit-rate of one or two bits per packet.
For more discussion of this issue please see
[I-D.ietf-tsvwg-ecn-tunnel].
We note that the end-point security functions needs to prevent an We note that the end-point security functions needs to prevent an
external attacker from affecting the solution easily are source external attacker from affecting the solution easily are source
authentication and integrity protection. To prevent what information authentication and integrity protection. To prevent what information
leakage there can be from the feedback encryption of the RTCP is also leakage there can be from the feedback encryption of the RTCP is also
needed. For RTP there exist multiple solutions possible depending on needed. For RTP there exist multiple solutions possible depending on
the application context. Secure RTP (SRTP) [RFC3711] does satisfy the application context. Secure RTP (SRTP) [RFC3711] does satisfy
the requirement to protect this mechanism despite only providing the requirement to protect this mechanism despite only providing
authentication if a entity is within the security context or not. authentication if a entity is within the security context or not.
IPsec [RFC4301] and DTLS [RFC4347] can also provide the necessary IPsec [RFC4301] and DTLS [RFC4347] can also provide the necessary
skipping to change at page 43, line 49 skipping to change at page 40, line 35
external attacker from modifying any signalling. Here an appropriate external attacker from modifying any signalling. Here an appropriate
mechanism to protect the used signalling needs to be used. For SIP/ mechanism to protect the used signalling needs to be used. For SIP/
SDP ideally S/MIME [RFC5751] would be used. However, with the SDP ideally S/MIME [RFC5751] would be used. However, with the
limited deployment a minimal mitigation strategy is to require use of limited deployment a minimal mitigation strategy is to require use of
SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least accomplish hop- SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least accomplish hop-
by-hop protection. by-hop protection.
We do note that certain mitigation methods will require network We do note that certain mitigation methods will require network
functions. functions.
10. Examples of SDP Signalling 11. Examples of SDP Signalling
(tbd) (tbd)
11. Open Issues 12. Open Issues
As this draft is under development some known open issues exist and As this draft is under development some known open issues exist and
are collected here. Please consider them and provide input. are collected here. Please consider them and provide input.
1. The negotiation and directionality attribute is going to need 1. The negotiation and directionality attribute is going to need
some consideration for multi-party sessions when readonly some consideration for multi-party sessions when readonly
capability might be sufficient to enable ECN for all incoming capability might be sufficient to enable ECN for all incoming
streams. However, it would beneficial to know if no potential streams. However, it would beneficial to know if no potential
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.
12. References 3. Should we report congestion in bytes or packets? RTCP usually
does this in terms of packets, but there may be an argument that
we want to report bytes for ECN.
draft-ietf-tsvwg-byte-pkt-congest is extremely unclear on what is
the right approach. (csp)
12.1. Normative References 4. Add examples of SDP signalling
13. References
13.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.
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
skipping to change at page 45, line 6 skipping to change at page 42, line 5
April 2010. April 2010.
[RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
Friendly Rate Control (TFRC): Protocol Specification", Friendly Rate Control (TFRC): Protocol Specification",
RFC 5348, September 2008. RFC 5348, September 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
12.2. Informative References 13.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-tsvwg-ecn-tunnel]
Briscoe, B., "Tunnelling of Explicit Congestion
Notification", draft-ietf-tsvwg-ecn-tunnel-08 (work in
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 Unicast Secure RTP", Path Key Agreement for Unicast Secure RTP",
draft-zimmermann-avt-zrtp-22 (work in progress), draft-zimmermann-avt-zrtp-22 (work in progress),
June 2010. June 2010.
[RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session
Announcement Protocol", RFC 2974, October 2000. Announcement Protocol", RFC 2974, October 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
skipping to change at page 47, line 15 skipping to change at page 44, line 15
Ericsson Ericsson
Laboratoriegrand 11 Laboratoriegrand 11
SE-971 28 Lulea SE-971 28 Lulea
SWEDEN SWEDEN
Phone: +46 73 0783289 Phone: +46 73 0783289
Email: ingemar.s.johansson@ericsson.com Email: ingemar.s.johansson@ericsson.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
Department of Computing Science School of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
Piers O'Hanlon Piers O'Hanlon
University College London University College London
Computer Science Department Computer Science Department
Gower Street Gower Street
London WC1E 6BT London WC1E 6BT
 End of changes. 122 change blocks. 
775 lines changed or deleted 613 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/