draft-westerlund-avt-ecn-for-rtp-00.txt   draft-westerlund-avt-ecn-for-rtp-01.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 7, 2010 C. Perkins Expires: April 5, 2010 C. Perkins
University of Glasgow University of Glasgow
July 6, 2009 P. O'Hanlon
UCL
K. Carlberg
G11
October 2, 2009
Explicit Congestion Notification (ECN) for RTP over UDP Explicit Congestion Notification (ECN) for RTP over UDP
draft-westerlund-avt-ecn-for-rtp-00 draft-westerlund-avt-ecn-for-rtp-01
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 38
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 7, 2010. This Internet-Draft will expire on April 5, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 14 skipping to change at page 2, line 18
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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 3
3. Discussion, Requirements, and Design Rationale . . . . . . . . 4 3. Discussion, Requirements, and Design Rationale . . . . . . . . 4
3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6
4. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 9 4. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 9
4.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 11 4.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 12
4.1.1. Signalling ECN Capability using SDP . . . . . . . . . 11 4.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 17
4.1.2. ICE Parameter to Signal ECN Capability . . . . . . . . 12 4.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 22
4.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 12 4.4. Detecting Failures and Receiver Misbehaviour . . . . . . . 26
4.2.1. Detection of ECT using RTP and RTCP . . . . . . . . . 13 5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 29
4.2.2. Detection of ECT using STUN with ICE . . . . . . . . . 15 5.1. ECN Feedback packet . . . . . . . . . . . . . . . . . . . 29
4.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 17 5.2. RTCP XR Report block for ECN summary information . . . . . 32
4.3.1. Transmission of ECT-marked RTP Packets . . . . . . . . 17 5.3. RTCP XR Report Block for ECN Nonce . . . . . . . . . . . . 34
4.3.2. Reporting ECN Feedback via RTCP . . . . . . . . . . . 17 6. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 37
4.3.3. Response to Congestion Notifications . . . . . . . . . 18 6.1. Fragmentation and Reassembly in Translators . . . . . . . 37
4.4. Detecting Failures and Receiver Misbehaviour . . . . . . . 20 6.2. Generating RTCP ECN Feedback in Translators . . . . . . . 37
4.4.1. Fallback mechanisms . . . . . . . . . . . . . . . . . 21 6.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 38
5. RTCP Extension for ECN feedback . . . . . . . . . . . . . . . 22 7. Implementation considerations . . . . . . . . . . . . . . . . 38
6. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
6.1. Fragmentation and Reassembly in Translators . . . . . . . 25 8.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 38
6.2. Generating RTCP ECN Feedback in Translators . . . . . . . 25 8.2. AVPF Transport Feedback Message . . . . . . . . . . . . . 39
6.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 25 8.3. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 39
7. Implementation considerations . . . . . . . . . . . . . . . . 26 8.4. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8.5. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 39
8.2. AVPF Transport Feedback Message . . . . . . . . . . . . . 26 10. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 42
8.3. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 26 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 42
8.4. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 42
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 12.2. Informative References . . . . . . . . . . . . . . . . . . 43
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
10.2. Informative References . . . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
1. Introduction 1. Introduction
This document outlines how Explicit Congestion Notification (ECN) This document outlines how Explicit Congestion Notification (ECN)
[RFC3168] can be used for RTP [RFC3550] flows running over UDP/IP [RFC3168] can be used for RTP [RFC3550] flows running over UDP/IP
which use RTCP as feedback mechanism. The solution consists of which use RTCP as feedback mechanism. The solution consists of
feedback of ECN congestion experienced markings to sender using RTCP, feedback of ECN congestion experienced markings to sender using RTCP,
verification of ECN functionality end-to-end, and how to initiate ECN verification of ECN functionality end-to-end, and how to initiate ECN
usage. The initiation process will have some dependencies on the usage. The initiation process will have some dependencies on the
signalling mechanism used to establish the RTP session, a signalling mechanism used to establish the RTP session, a
specification for mechanisms using SDP is included. specification for mechanisms using SDP is included.
ECN is getting attention as a method to minimise the impact of ECN is getting attention as a method to minimise the impact of
congestion on real-time multimedia traffic. This as packet loss can congestion on real-time multimedia traffic. When ECN is used, the
be avoided if transmission rate adjustments are quick enough. network can signal to applications that congestion is occurring,
Including congestion in wireless access networks when radio resources whether that congestion is due to queuing at a congested link,
and coverage is insufficient to maintain the current media rates. limited resources and coverage on a radio link, or other reasons.
One key benefit with ECN is it is a lightweight mechanism to allow This congestion signal allows applications to reduce their
for each node along the transmission path to set a congestion transmission rate in a controlled manner, rather than responding to
notification in the IP header, thereby letting the endpoints know of uncontrolled packet loss, and so improves the user experience while
the congested situation. benefiting the network.
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 has to be the network and transport layers. At the network layer, IP
updated to allow routers to mark packets, rather than discarding them forwarding has to be updated to allow routers to mark packets, rather
in times of congestion [RFC3168]. In addition, transport protocols than discarding them in times of congestion [RFC3168]. In addition,
have to be modified to inform that sender that ECN marked packets are transport protocols have to be modified to inform that sender that
being received, so it can respond to the congestion. TCP [RFC3168], ECN marked packets are being received, so it can respond to the
SCTP [RFC4960] and DCCP [RFC4340] have been updated to support ECN, congestion. TCP [RFC3168], SCTP [RFC4960] and DCCP [RFC4340] have
but to date there is no specification how UDP-based transports, such been updated to support ECN, but to date there is no specification
as RTP [RFC3550], can be used with ECN. how UDP-based transports, such as RTP [RFC3550], can use ECN. This
is due to the lack of feedback mechanism directly in UDP. Instead
the protocol on top of UDP needs to provide that feedback, which for
RTP is RTCP.
The remainder of this memo is structured as follows. We start by The remainder of this memo is structured as follows. We start by
describing the conventions, definitions and acronyms used in this describing the conventions, definitions and acronyms used in this
memo in Section 2, and the design rationale and applicability in memo in Section 2, and the design rationale and applicability in
Section 3. The means by which ECN is used with RTP over UDP is Section 3. The means by which ECN is used with RTP over UDP is
defined in Section 4, along with RTCP extensions for ECN feedback in defined in Section 4, along with RTCP extensions for ECN feedback in
Section 5. In Section 6 we discuss how RTCP ECN feedback is handled Section 5. In Section 6 we discuss how RTCP ECN feedback is handled
in RTP translators. Section 7 discusses some implementation in RTP translators and mixers. Section 7 discusses some
considerations, Section 8 lists IANA considerations, and Section 9 implementation considerations, Section 8 lists IANA considerations,
discusses the security considerations. and Section 9 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 ECN: Explicit Congestion Notification
skipping to change at page 5, line 42 skipping to change at page 5, line 48
requirements that must be satisfied to at least some degree if ECN is requirements that must be satisfied to at least some degree if ECN is
used by an other protocol (such as RTP over UDP) used by an other protocol (such as RTP over UDP)
o REQ 1: A mechanism to negotiate and initiate the usage of ECN for o REQ 1: A mechanism to negotiate and initiate the usage of ECN for
RTP/UDP/IP sessions is required RTP/UDP/IP sessions is required
o REQ 2: A mechanism to feedback the reception of any packets that o REQ 2: A mechanism to feedback the reception of any packets that
are ECN-CE marked to the packet sender is required are ECN-CE marked to the packet sender is required
o REQ 3: Provide mechanism to minimise the possibility for cheating o REQ 3: Provide mechanism to minimise the possibility for cheating
is preferable is desirable
o REQ 4: Some detection and fallback mechanism is needed in case an o REQ 4: Some detection and fallback mechanism is needed to avoid
intermediate node clears ECT or drops packets with ECT set to loss of communication due to the attempted usage of ECN in case an
avoid loss of communication due to the attempted usage of ECN. 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). before the media can flow is unlikely to be acceptable for some
use cases).
o REQ 6: Negotiation of ECN should not cause clipping at the start o REQ 6: Negotiation of ECN should not cause media clipping at the
of a session. start of a session.
The following sections describes how these requirements can be meet The following sections describes how these requirements can be meet
for RTP over UDP. for RTP over UDP.
3.2. Applicability 3.2. Applicability
The use of ECN with RTP over UDP is dependent on negotiation of ECN The use of ECN with RTP over UDP is dependent on negotiation of ECN
capability between the sender and receiver(s), and validation of ECN capability between the sender and receiver(s), and validation of ECN
support in all elements of the network path(s) traversed. RTP is support in all elements of the network path(s) traversed. RTP is
used in a heterogeneous range of network environments and topologies, used in a heterogeneous range of network environments and topologies,
skipping to change at page 6, line 50 skipping to change at page 7, line 6
[I-D.ietf-avt-rtcpssm]), and can be used by a sender to determine [I-D.ietf-avt-rtcpssm]), and can be used by a sender to determine
if all its receivers, and the network paths to those receivers, if all its receivers, and the network paths to those receivers,
support ECN (see Section 4.2). It is somewhat more difficult to support ECN (see Section 4.2). It is somewhat more difficult to
determine if all network paths from all senders to all receivers determine if all network paths from all senders to all receivers
support ECN. Accordingly, we allow ECN to be used by an RTP support ECN. Accordingly, we allow ECN to be used by an RTP
sender using multicast UDP provided the sender has verified that sender using multicast UDP provided the sender has verified that
the paths to all its known receivers support ECN, and irrespective the paths to all its known receivers support ECN, and irrespective
of whether the paths from other senders to their receivers support of whether the paths from other senders to their receivers support
ECN. Note that group membership may change during the lifetime of ECN. Note that group membership may change during the lifetime of
a multicast RTP session, potentially introducing new receivers a multicast RTP session, potentially introducing new receivers
that are not ECN capable. Senders MUST use the mechanisms that are not ECN capable. Senders must use the mechanisms
described in Section 4.4 to monitor that all receivers continue to described in Section 4.4 to monitor that all receivers continue to
support ECN, and MUST fallback to non-ECN use if they do not. support ECN, and needs to fallback to non-ECN use if they do not.
Topo-Translator: An RTP translator is an RTP-level middlebox that is Topo-Translator: An RTP translator is an RTP-level middlebox that is
invisible to the other participants in the RTP session (although invisible to the other participants in the RTP session (although
it is usually visible in the associated signalling session). it is usually visible in the associated signalling session).
There are two types of RTP translator: those do not modify the There are two types of RTP translator: those do not modify the
media stream, and are concerned with transport parameters, for media stream, and are concerned with transport parameters, for
example a multicast to unicast gateway; and those that do modify example a multicast to unicast gateway; and those that do modify
the media stream, for example transcoding between different media the media stream, for example transcoding between different media
codecs. A single RTP session traverses the translator, and the codecs. A single RTP session traverses the translator, and the
translator must rewrite RTCP messages passing through it to match translator must rewrite RTCP messages passing through it to match
skipping to change at page 7, line 34 skipping to change at page 7, line 39
datagrams, unless it is overloaded and experiencing congestion, datagrams, unless it is overloaded and experiencing congestion,
in which case it may mark the outgoing datagrams with an ECN-CE in which case it may mark the outgoing datagrams with an ECN-CE
mark. Such a translator passes RTCP feedback unchanged. mark. Such a translator passes RTCP feedback unchanged.
* If the translator modifies the media stream to combine or split * If the translator modifies the media stream to combine or split
RTP packets, but does not otherwise transcode the media, it RTP packets, but does not otherwise transcode the media, it
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 have a random ECT mark otherwise. When RTCP marked, and should be ECT marked if any of the incoming packets
ECN feedback packets (Section 5) are received, they must be are ECT marked. When RTCP ECN feedback packets (Section 5) are
rewritten to match the modifications made to the media stream received, they must be rewritten to match the modifications
(see Section 6.1). made to the media stream (see Section 6.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
synthetic 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 6.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: This is an RTP-level middlebox that aggregates multiple Topo-Mixer: This is an RTP-level middlebox that aggregates multiple
RTP streams, mixing them together to generate a new RTP stream. RTP streams, mixing them together to generate a new RTP stream.
The mixer is visible to the other participants in the RTP session. The mixer is visible to the other participants in the RTP session.
The RTP flows on each side of the mixer are treated independently The RTP flows on each side of the mixer are treated independently
for ECN purposes, with the mixer generating its own RTCP ECN for ECN purposes, with the mixer generating its own RTCP ECN
feedback, and responding to ECN feedback for data it sends. Since feedback, and responding to ECN feedback for data it sends. Since
connections are treated independently, it would seem reasonable to connections are treated independently, it would seem reasonable to
allow the transport on one side of the mixer to use ECN, while the allow the transport on one side of the mixer to use ECN, while the
transport on the other side of the mixer is not ECN capable. transport on the other side of the mixer is not ECN capable, if
this is desired.
Topo-Video-switch-MCU: A video switching MCU receives several RTP Topo-Video-switch-MCU: A video switching MCU receives several RTP
flows, but forwards only one of those flows onwards to the other flows, but forwards only one of those flows onwards to the other
participants at a time. The flow that is forwarded changes during participants at a time. The flow that is forwarded changes during
the session, often based on voice activity. Since only a subset the session, often based on voice activity. Since only a subset
of the RTP packets generated by a sender are forwarded to the of the RTP packets generated by a sender are forwarded to the
receivers, a video switching MCU can break ECN negotiation (the receivers, a video switching MCU can break ECN negotiation (the
success of the ECN negotiation depends on the voice activity of success of the ECN negotiation may depend on the voice activity of
the participant at the instant the negotiation takes place - shout the participant at the instant the negotiation takes place - shout
if you want ECN). It also breaks congestion feedback and if you want ECN). It also breaks congestion feedback and
response, since RTP packets are dropped by the MCU depending on response, since RTP packets are dropped by the MCU depending on
voice activity rather than network congestion. This topology is voice activity rather than network congestion. This topology is
widely used in legacy products, but is NOT RECOMMENDED for new widely used in legacy products, but is NOT RECOMMENDED for new
implementations and cannot be used with ECN. implementations and cannot be used with ECN.
Topo-RTCP-terminating-MCU: In this scenario, each participant runs Topo-RTCP-terminating-MCU: In this scenario, each participant runs
an RTP point-to-point session between itself and the MCU. Each of an RTP point-to-point session between itself and the MCU. Each of
these sessions is treated independently for the purposes of ECN these sessions is treated independently for the purposes of ECN
and RTCP feedback, potentially with some using ECN and some not. and RTCP feedback, potentially with some using ECN and some not.
Topo-Asymmetric: It is theoretically possible to build a middlebox Topo-Asymmetric: It is theoretically possible to build a middlebox
that is a combination of an RTP mixer in one direction and an RTP that is a combination of an RTP mixer in one direction and an RTP
translator in the other. To quote RFC 5117 "This topology is so translator in the other. To quote RFC 5117 "This topology is so
problematic and it is so easy to get the RTCP processing wrong, problematic and it is so easy to get the RTCP processing wrong,
that it is NOT RECOMMENDED to implement this topology." that it is NOT RECOMMENDED to implement this topology."
These topologies may be combined within a single RTP session. These topologies may be combined within a single RTP session.
This ECN mechanism is applicable to both sender and receiver The ECN mechanism defined in this memo is applicable to both sender
controlled congestion algorithms. The mechanism ensures that both and receiver controlled congestion algorithms. The mechanism ensures
senders and receivers will know about ECN-CE markings and any packet that both senders and receivers will know about ECN-CE markings and
losses. Thus the actual decision point for the congestion control is any packet losses. Thus the actual decision point for the congestion
not relevant. This is a great benefit as RTP session can be adapted control is not relevant. This is a great benefit as RTP session can
in a number of ways, such as media sender using TFRC [RFC5348] or be adapted in a number of ways, such as media sender using TFRC
other algorithms, or for multicast sessions either a sender based [RFC5348] or other algorithms, or for multicast sessions either a
scheme with lowest common rate, or receiver driven mechanism based on sender based scheme with lowest common rate, or receiver driven
layers to support more heterogeneous paths. mechanism based on layers to support more heterogeneous paths.
To ensure timely feedback of CE marked packets, this mechanism
requires support for the RTP/AVPF profile [RFC4585] or any of its
derivatives, such as RTP/SAVPF [RFC5124]. The standard RTP/AVP
profile [RFC3551] does not allow any early or immediate transmission
of RTCP feedback, and has a minimal RTCP interval whose default value
(5 seconds) is many times the normal RTT between sender and receiver.
The 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
not be ECT marked, whether generated by sender or receivers.
4. Use of ECN with RTP/UDP/IP 4. Use of ECN with RTP/UDP/IP
The solution for using ECN with RTP consists of a few different The solution for using ECN with RTP over UDP/IP consists of four
pieces that together makes the solution work: different pieces that together makes the solution work:
1. Negotiation of the capability to do ECN with RTP/UDP 1. Negotiation of the capability to use ECN with RTP/UDP
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. Failure detection, verification and fallback
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 4.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 support ECN (for example, a firewall that participants which don't support ECN (for example, a firewall that
blocks traffic with the ECN bits set). blocks traffic with the ECN bits set). This document defines the
information that needs to be negotiated, and provides a mapping to
SDP for use in both declarative and offer/answer contexts.
When a sender joins a session for which all participants claim ECN When a sender joins a session for which all participants claim ECN
capability, it must verify if that capability is usable. There are capability, it must verify if that capability is usable. There are
two ways in which this verification may be done (Section 4.2): three ways in which this verification phase may be done
(Section 4.2):
o The sender may generate a subset of its RTP data packets with the o The sender may generate a (small) subset of its RTP data packets
ECN field set to ECT(0) or ECT(1). Each receiver will then send with the ECN field set to ECT(0) or ECT(1). Each receiver will
an RTCP feedback packet indicating the reception of the ECT marked then send an RTCP feedback packet indicating the reception of the
RTP packets. Upon reception of this feedback from each receiver ECT marked RTP packets. Upon reception of this feedback from each
it knows of, the sender can consider ECN functional for its receiver it knows of, the sender can consider ECN functional for
traffic. Each sender does this verification independently of each its traffic. Each sender does this verification independently of
other. If a new receiver join an existing session it also needs each other. If a new receiver joins an existing session it also
to verify ECN support. If verification fails the sender needs to needs to verify ECN support. If verification fails the sender
stop using ECN. As the sender will not know of the receiver prior needs to stop using ECN. As the sender will not know of the
to it sending RTP or RTCP packets, the sender will wait for the receiver prior to it sending RTP or RTCP packets, the sender will
first RTCP packet from the new receiver to determine if that wait for the first RTCP packet from the new receiver to determine
contains ECN feedback or not. if that contains ECN feedback or not.
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 now with the ECN field set to capability an extra STUN exchange, this time with the ECN field
ECT is performed. If successful the paths capability is verified. 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
attribute is defined to convey feedback that the ECT marked
request was received.
Through the use of an extra STUN attribute also support for this o Thirdly, make a leap of faith that it will work. This is only
solution can be verified through that mechanism. recommended in applications that know they run in controlled
environments where ECN functionality through other means have been
verified. In this mode one assumes ECN to work and then reacts to
failure indicators if the assumption proved wrong. The usage of
this method relies on a high confidence in successful ECN function
or an application where failure are not serious. However, also
the impact on the network and other users must be considered.
Thus there are limitation to when this method is allowed.
The first mechanism, using RTP with RTCP feedback, has the advantage The first mechanism, using RTP with RTCP feedback, has the advantage
of working for all RTP sessions, but the disadvantages of potential of working for all RTP sessions, but the disadvantages of potential
clipping if ECN marked RTP packets are discarded by middleboxes, and clipping if ECN marked RTP packets are discarded by middleboxes, and
slow verification of ECN support. The STUN-based mechanism is faster slow verification of ECN support. The STUN-based mechanism is faster
to verify ECN support, but only works in those scenarios supported by to verify ECN support, but only works in those scenarios supported by
end-to-end STUN, such as within an ICE exchange. end-to-end STUN, such as within an ICE exchange. The third one,
leap-of-faith, has the advantage of avoiding additional tests or
complexities and enabling ECN usage from the first media packet. The
downside is that if the end-to-end path contains middleboxes that do
not pass ECN, the impact on the application can be severe: in the
worst case, all media could be lost if a middlebox that discards ECN
marked packets is present. A less severe effect, but still requiring
reaction, is the presence of a middlebox that remarks ECT marked
packets to non-ECT, possibly marking packets with a CE mark as non-
ECT. This can force the network into heavy congestion due to non-
responsiveness, and seriously impact media quality.
Once ECN support has been verified to work for all receivers, a Once ECN support has been verified (or assumed) to work for all
sender marks all its RTP packets as ECT packets, while receivers receivers, a sender marks all its RTP packets as ECT packets, while
feedback any CE marks to the sender using RTCP in RTP/AVPF immediate receivers rapidly feedback any CE marks to the sender using RTCP in
or early feedback mode (see Section 4.3). An RTCP feedback report is RTP/AVPF immediate or early feedback mode (see Section 4.3). An RTCP
sent as soon as possible by the transmission rules for feedback that feedback report is sent as soon as possible by the transmission rules
are in place. This feedback report contains all the CE marks that for feedback that are in place. This feedback report indicates new
has been received since the last regular report until the sending of CE marks since last ECN feedback packet and also the number of new CE
this packet. This is the mechanism to provide the fastest possible marks through a accumulative sum. This is the mechanism to provide
feedback to senders about CE marks. On receipt of an RTCP report the fastest possible feedback to senders about CE marks. On receipt
indicating that CE marked packets were received, the sender must of a CE marked packet, the system must react to congestion as-if
reduce its sending rate as-if packet loss were reported. packet loss has been reported.
RTCP traffic is never ECT marked for the following reason. ECT This rapid feedback is not optimised for reliability, therefore an
additional procedure is used to ensure more reliable, but less
timely, reporting of the ECN information. An ECN summary report
should also be sent in regular RTCP reports. The ECN summary report
contains the same information as the ECN feedback format, only packed
differently for better efficiency with large reports. By using
accumulative counters for seen CE, ECT, not-ECT or packet loss the
sender can determine what events has happened since the last report,
independently of any RTCP packets having been lost.
RTCP traffic must not be ECT marked for the following reason. ECT
marked traffic may be dropped if the path is not ECN compliant. As marked traffic may be dropped if the path is not ECN compliant. As
RTCP is used to provide feedback about what has been transmitted and RTCP is used to provide feedback about what has been transmitted and
what ECN markings that are received it is important that these are what ECN markings that are received it is important that these are
received in cases when ECT marked traffic is not getting through. received in cases when ECT marked traffic is not getting through.
The above feedback is not optimised for reliability, therefore an There are numerous reasons why the path the RTP packets take from the
additional procedure is used to ensure more reliable but less timely
reporting of the ECN information. The ECN feedback report is also
sent in the regular RTCP receiver reports. In this case they include
the ECN information covering the last three reporting intervals.
That way a loss of ECN-CE report will with high reliability be
eventual reported.
There a numerous reasons why the path the RTP packets take from the
sender to the receiver may change, e.g. mobility, link failure sender to the receiver may change, e.g. mobility, link failure
followed by re-routing around it. Such an event may result in the followed by re-routing around it. Such an event may result in the
packet being sent through a node that are ECN non-compliant, thus packet being sent through a node that is ECN non-compliant, thus
remarking or dropping packets with ECT set. To prevent this from remarking or dropping packets with ECT set. To prevent this from
impacting the application for any longer duration the function of ECN impacting the application for longer than necessary, the operation of
is constantly monitored using the ECN feedback information. By using ECN is constantly monitored by all senders. Both the RTCP ECN
an ECN nonce over all the received packet that where not ECN-CE summary reports and the ECN feedback packets allow the sender to
marked and reported explicitly the sender can detect if any remarking compare the number of ECT(0), ECT(1), and non-ECT marked packet with
happens. If ECT marked packets are being dropped that will evident those that were sent, while also reporting CE marked and lost
from the RTCP receiver report where the "extended highest sequence packets. If these numbers do not agree with what was sent, it can be
number received" field will stop advancing or if the loss is not 100% inferred that the path does not reliably pass ECN-marked packets.
the high reported packet loss rates. A sender detecting a possible More detailed discussions are presented in Section 4.4 and
ECN non-compliance issue can then stop sending ECT marked packets to Section 4.4.2 on how to interpret different cases. A sender
determine if that allows the packet to be correctly delivered. If detecting a possible ECN non-compliance issue should then stop
the issues can be connected to ECN, then ECN usage is suspended and sending ECT marked packets to determine if that allows the packet to
possibly also re-negotiated. be correctly delivered. If the issues can be connected to ECN, then
ECN usage is suspended and possibly also re-negotiated.
In the below detailed specification of the behaviour for the This specification offers an option of computing and reporting an ECN
different functions the general case will first be discussed. In nonce over all received packets that where not ECN-CE marked or
cases special considerations are needed for middleboxes, multicast reported explicitly lost. Thus, the sender will have an additional
usage etc, those will be specially discussed in related subsections. tool to detect if any remarking happens. It can also based on
statistics detect receivers that suppress reporting of CE marked
packets, i.e. detect cheating. The incentive for a real-time
application to cheat in its ECN reporting is less than for TCP, as
increased congestion levels are likely to cause packet losses that
decrease the media quality. While for TCP lying allows for keeping a
larger congestion window than compliant receivers and any packet
losses will be corrected by TCP's retransmission. The ECN nonce
mechanism also requires more data to function correctly. To enable
the sender to verify the ECN nonce, the sender must learn the
sequence number of all packets that was either CE marked or lost.
Otherwise it can't correctly exclude these packet from the ECN nonce
sum. This is done using a RTCP XR Nonce report, containing the nonce
sums and indicating the lost or ECN-CE marked packets using a run
length encoded bit-vector. Thus ECN nonce has a higher demand for
RTCP bandwidth. Combined with the reduced incentive to cheat, this
mechanism is optional and is only recommended for applications where
the incentive might be higher, such as streaming with
retransmissions.
In the detailed specification of the behaviour below, the different
functions the general case will first be discussed. In cases special
considerations are needed for middleboxes, multicast usage etc, those
will be specially discussed in related subsections.
4.1. Negotiation of ECN Capability 4.1. Negotiation of ECN Capability
The first stage of ECN negotiation for RTP-over-UDP is to signal The first stage of ECN negotiation for RTP-over-UDP is to signal the
support for ECN capability. There are two signalling schemes that capability to use ECN. This includes negotiating if ECN is to be
may be used, depending on how ECN usage is to be initiated: an SDP used symmetrically, the method for initial ECT verification, and
extension to indicate that ECN support should be negotiated using RTP whether the ECN nonce is to be used. This memo defines the mappings
and RTCP, and an ICE parameter to indicate that ECN support should be of this information onto SDP both for declarative and offer/answer
negotiated using STUN as part of an ICE exchange. usage. There are one SDP extension to indicate if ECN support should
be used and the method for initiation. In addition there are an ICE
parameter to indicate that ECN initiation using STUN as part of an
ICE exchange is supported.
An RTP system that supports ECN MUST implement the SDP extension to An RTP system that supports ECN and uses SDP in the signalling MUST
signal ECN capability as described in Section 4.1.1. It MAY also implement the SDP extension to signal ECN capability as described in
implement other ECN capability negotiation schemes, such as the ICE Section 4.1.1. It MAY also implement alternative ECN capability
extension described in Section 4.1.2. negotiation schemes, such as the ICE extension described in
Section 4.1.2.
4.1.1. Signalling ECN Capability using SDP 4.1.1. Signalling ECN Capability using SDP
One new SDP attribute, "a=ecn-capable-rtp", is defined. This is a One new SDP attribute, "a=ecn-capable-rtp", is defined. This is a
media level attribute, which MUST NOT be used at the session level. media level attribute, which MUST NOT be used at the session level.
It is not subject to the character set chosen. The aim of this It is not subject to the character set chosen. The aim of this
signalling is to indicate the capability of the sender and receivers signalling is to indicate the capability of the sender and receivers
to support ECN. If all parties have the capability to use ECN then to support ECN, and to negotiate the method for ECN initiation to be
some on-path mechanism must be used to negotiate its use, and to used in the session. Thus the attribute take a list of methods for
check that all middleboxes on the path support ECN (Section 4.2.1 initiation, which are ordered in decreasing preference. The defined
describes such a mechanism). values for the initiation method are:
rtp: Using RTP and RTCP as defined in Section 4.2.1.
ice: Using STUN within ICE as defined in Section 4.2.2.
leap: Using the leap of faith method as defined in Section 4.2.3.
In addition, a number of OPTIONAL parameters may be included in the
"a=ecn-capable-rtp" attribute as follows:
o The "mode" parameter signals the endpoint's capability to set and
read ECN marks in UDP packets. An examination of various
operating systems has shown that end-system support for ECN
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
an outgoing UDP packet but not read them, while others may allow
applications to read the ECN bits but not set them. This
either/or case may produce an asymmetric support for ECN and thus
should be conveyed in the SDP signalling. The "mode=setread"
state is the ideal condition where an endpoint can both set and
read ECN bits in UDP packets. The "mode=setonly" state indicates
that an endpoint can set the ECT bit, but cannot read the ECN bits
from received UDP packets to determine if upstream congestion
occurred. The "mode=readonly" state indicates that the endpoint
can read the ECN bits to determine if downstream congestion has
occurred, but it cannot set the ECT bits in outgoing UDP packets.
When the "mode=" parameter is omitted it is assumed that the node
has "setread" capabilities. This option can provide for an early
indication that ECN cannot be used in a session. This would be
case when both the offerer and answerer set the "mode=" parameter
to "setonly" or "readonly", or when an RTP sender entity considers
offering "readonly".
o The "nonce" parameter may be used to signal whether the ECN nonce
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.
o The "ect" parameter makes it possible to express the preferred ECT
marking. This is either random (default), ECT(0) or ECT(1). If
the ECN nonce is used then this parameter MUST be ignored, and
random ECT is implied. The "ect" parameter describes a receiver
preference, and is useful in the case where the receiver knows it
is behind a link using IP header compression, the efficiency of
which would be seriously disrupted if it were to receive packets
with randomly chosen ECT marks.
The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp" attribute is
as follows:
ecn-attribute = "a=ecn-capable-rtp" init-list parameter-list
init-list = init-value *("," init-value)
init-value = "rtp" / "ice" / "leap" / init-ext
init-ext = token
parameter-list = *(SP ";" par-value)
par-value = nonce / mode / ect / (parameter "=" value)
mode = "mode=" ("setonly" / "setread" / "readonly")
nonce = "nonce=" ("0" / "1")
ect = "ect=" ("random" / "0" / "1")
parameter = token
value = token / quoted-string
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 /
%x41-5A / %x5E-7A / %x7C / %x7E)
quoted-string = ( DQ *qdtext DQ )
qdtext = %x20-21 / %x23-7E / %x80-FF
DQ = %x22 ; US-ASCII double-quote mark (34)
When SDP is used with the offer/answer model [RFC3264], the party When SDP is used with the offer/answer model [RFC3264], the party
generating the SDP offer must insert an "a=ecn-capable-rtp" attribute generating the SDP offer MUST insert an "a=ecn-capable-rtp" attribute
into the media section of the SDP offer of each RTP flow for which it into the media section of the SDP offer of each RTP flow for which it
wishes to use ECN. The answering party includes this same attribute wishes to use ECN. The attribute includes one or more ECN initiation
in the media sections of the answer if it has the capability, and methods in a comma separated list in decreasing order of preference,
wishes to, use ECN, or removes it for those flows for which it does with some number of optional parameters following. The answering
not want to use ECN. If the attribute is removed then ECT MUST NOT party compares the list of initiation methods in the offer with those
be used in any direction for that media flow. it supports in order of preference. If there is a match, and if the
receiver wishes to attempt to use ECN in the session, it includes an
"a=ecn-capable-rtp" attribute containing its single preferred choice
of initiation method in the media sections of the answer. If there
is no matching initiation method capability, or if the receiver does
not wish to attempt to use ECN in the session, it does not include an
"a=ecn-capable-rtp" attribute in its answer. If the attribute is
removed then ECN MUST NOT be used in any direction for that media
flow. The answer may also include optional parameters, as discussed
below.
When SDP is used in a declarative manner, for example a multicast If the "mode=setonly" parameter is present in the "a=ecn-capable-rtp"
attribute of the offer and the answering party is also
"mode=setonly", then there is no common ECN capability, and the
answer MUST NOT include the "a=ecn-capable-rtp" attribute.
Otherwise, if the offer is "mode=setonly" then ECN may only be
initiated in the direction from the offering party to the answering
party.
If the "mode=readonly" parameter is present in the "a=ecn-capable-
rtp" attribute of the offer and the answering party is
"mode=readonly", then there is no common ECN capability, and the
answer MUST NOT include the "a=ecn-capable-rtp" attribute.
Otherwise, if the offer is "mode=readonly" then ECN may only be
initiated in the direction from the answering party to the offering
party.
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
may only be initiated in the direction from the answering party to
the offering party. If the offering party is "mode=setread" but the
answering party is "mode=readonly", then ECN may only be initiated in
the direction from the offering party to the answering party. If
both offer and answer are "mode=setread", then ECN may be initiated
in both directions. Note that "mode=setread" is implied by the
absence of a "mode=" parameter in the offer.
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
independently in the offer and the answer. Its value in the offer
indicates a preference for the behaviour of the answering party, and
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
receivers preference or not.
When SDP is used in a declarative manner, for example in a multicast
session using SAP, negotiation of session description parameters is session using SAP, negotiation of session description parameters is
not possible. The "a=ecn-capable-rtp" attribute MAY be added to the not possible. The "a=ecn-capable-rtp" attribute MAY be added to the
session description to indicate that the sender will use ECN in the session description to indicate that the sender will use ECN in the
RTP session. Receivers MUST NOT join such a session unless they have RTP session. The attribute MUST include a single method of
the capability to understand ECN-marked UDP packets, and can generate initiation. Participants MUST NOT join such a session unless they
RTCP ECN feedback (note that having the capability to use ECN doesn't have the capability to understand ECN-marked UDP packets, implement
necessarily imply that the underlying network path between sender and the method of initiation, and can generate RTCP ECN feedback (note
receiver supports ECN). that having the capability to use ECN doesn't necessarily imply that
the underlying network path between sender and receiver supports
ECN). If the nonce parameter is included the ECN nonce shall be used
in the session. The mode parameter MAY be included also in
declarative usage, to indicate which capability is required by the
consumer of the SDP. So for example in a SSM session the
participants configured with a particular SDP will all be in a media
receive only mode, thus mode=readonly will work as the capability of
reporting on the ECN markings in the received is what is required.
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, most RTP sessions using ECN require As described in Section 4.3.3, RTP sessions using ECN require rapid
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. If such rapid feedback is required, the use of the marked packets. Thus, the use of the Extended RTP Profile for RTCP-
Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) [RFC4585] Based Feedback (RTP/AVPF) [RFC4585] MUST be signalled.
MUST be signalled.
When using ECN nonce, the RTCP XR signalling indicating the ECN Nonce
report MUST also be included in the SDP following [RFC3611].
4.1.2. ICE Parameter to Signal ECN Capability 4.1.2. ICE Parameter to Signal ECN Capability
One new ICE [I-D.ietf-mmusic-ice] option, "rtp+ecn", is defined. One new ICE [I-D.ietf-mmusic-ice] option, "rtp+ecn", is defined.
This is used with the SDP session level "a=ice-options" attribute in This is used with the SDP session level "a=ice-options" attribute in
an SDP offer to indicate that the initiator of the ICE exchange has an SDP offer to indicate that the initiator of the ICE exchange has
the capability to support ECN for RTP-over-UDP flows (via "a=ice- the capability to support ECN for RTP-over-UDP flows (via "a=ice-
options: rtp+ecn"). The answering party includes this same attribute options: rtp+ecn"). The answering party includes this same attribute
at the session level in the SDP answer if it has the capability, and at the session level in the SDP answer if it also has the capability,
wishes to, use ECN, and removes the attribute if it does not wish to and removes the attribute if it does not wish to use ECN, or doesn't
use ECN, or doesn't have the capability to use ECN. have the capability to use ECN. If this initiation method
(Section 4.2.2) actually is going to be used, it is explicitly
If both sides in the ICE exchange have the capability to use ECN, negotiated using the "a=ecn-capable-rtp" attribute.
then they will try to initiate ECN usage using the mechanisms we
describe in Section 4.2.2 for any nominated candidate that uses UDP
as transport protocol for an RTP session and which also include the
"a=ecn-capable-rtp" attribute associated with that media line. They
MUST NOT try to initiate ECN usage for RTP sessions using TCP, SCTP,
or DCCP transport, or for non-RTP sessions.
As described in Section 4.3.3, most RTP sessions using ECN require Note: This signalling mechanism is not strictly needed as long as
rapid RTCP ECN feedback, in order that the sender can react to ECN-CE the STUN ECN testing capability is used within the context of this
marked packets. If such rapid feedback is required, the use of the document. It may however be useful if the ECN verification
Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) [RFC4585] capability is used in additional contexts.
MUST be signalled, even when ECN capability negotiation is done
through ICE.
4.2. Initiation of ECN Use in an RTP Session 4.2. Initiation of ECN Use in an RTP Session
At the start of the RTP session when the first packets with ECT is Once the sender and the receiver(s) have agreed that they have the
capability to use ECN within a session, they may attempt to initiate
ECN use.
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 its destination(s). There is some risk of ECT or ECN-CE will reach its destination(s). There is some risk
that the usage of ECN will result in either reset of the ECN field or that the usage 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 receiver exhibits either of these behaviours one the sender and the receiver 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
during both the initiation and full usage of ECN with RTP. This is during both the initiation and full usage of ECN with RTP. This is
to ensure that packet loss due to ECN marking will not effect the to ensure that packet loss due to ECN marking will not effect the
RTCP traffic and the necessary feedback information. RTCP traffic and the necessary feedback information.
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 RTP and RTCP described in Section 4.2.1. It MAY also implement using RTP and RTCP described in Section 4.2.1. It MAY also implement
other mechanisms to initiate ECN support, for example the STUN-based other mechanisms to initiate ECN support, for example the STUN-based
mechanism described in Section 4.2.2. If support for both mechanisms mechanism described in Section 4.2.2 or use the leap of faith option
is signalled, the sender should try ECN negotiation using STUN with if the session supports the limitations provided in Section 4.2.3.
ICE first, and if it fails, fallback to negotiation using RTP and If support for both mechanisms is signalled, the sender should try
RTCP ECN feedback. ECN negotiation using STUN with ICE first, and if it fails, fallback
to negotiation using 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 receivers, to support monitor the ability of the network, and all receivers, to support
ECN, following the mechanisms described in Section 4.4. This is ECN, following the mechanisms described in Section 4.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 network to support ECN.
4.2.1. Detection of ECT using RTP and RTCP 4.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 fraction of its traffic with ECT marks to act a probe generates some fraction of its traffic with ECT marks to act a probe
for ECN support. Then, on receipt of these ECT-marked packets, the for ECN support. Then, on receipt of these ECT-marked packets, the
receivers send RTCP ECN feedback packets to inform the sender that receivers send RTCP ECN feedback packets and RTCP ECN summary reports
their path supports ECN. Finally, the RTP sender makes the decision to inform the sender that their path supports ECN. Finally, the RTP
to use ECN or not, based on whether the paths to all RTP receivers sender makes the decision to use ECN or not, based on whether the
have been verified to support ECN. 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 reason while leaving the reminder of the packets unmarked. The main
for only marking some packets is to maintain usable media delivery reason for only marking some packets is to maintain usable media
during the ECN initiation phase in those cases where ECN is not delivery during the ECN initiation phase in those cases where ECN
supported by the network path. An RTP sender is RECOMMENDED to is not supported by the network path. A secondary reason to send
send a minimum of two packets with ECT markings per RTCP reporting some not-ECT packets are to ensure that the receivers will send
interval, one with ECT(0) and one with ECT(1), and will continue RTCP reports on this sender, even if all ECT marked packets are
to send some ECT marked traffic as long as the ECN initiation lost in transit. The not-ECT packets also provide a base-line to
phase continues. The sender MUST NOT mark all RTP packets as ECT compare performance parameters against. An RTP sender is
during the ECN initiation phase. 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,
would be an appropriate choice. No matter which RTP packets are would be an appropriate choice. No matter which RTP packets are
marked, those packets MUST NOT be duplicated in transmission, marked, those packets MUST NOT be duplicated in transmission,
since their RTP sequence number is used to identify packets that since their RTP sequence number is used to identify packets that
are received with ECN markings. are received with ECN markings.
Generating RTCP ECN Feedback: If ECN capability has been negotiated Generating RTCP ECN Feedback: If ECN capability has been negotiated
in an RTP session, the participants in the session MUST listen for in an RTP session, the participants in the session MUST listen for
ECT or ECN-CE marked RTP packets, and generate RTCP ECN feedback ECT or ECN-CE marked RTP packets, and generate RTCP ECN feedback
packets (Section 5) to mark their receipt. If the use of the packets (Section 5) to mark their receipt. An immediate or early
Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) has been (depending on the RTP/AVPF mode) ECN feedback packet SHOULD be
negotiated, then an immediate or early (depending on the RTP/AVPF generated on receipt of the first ECT or ECN-CE marked packet from
mode) feedback packet SHOULD be generated on receipt of the first a sender that has not previously sent any ECT traffic. Each
ECT or ECN-CE marked packet from a sender that has not previously regular RTCP report MUST contain an ECN summary report
sent any ECT traffic. If RTP/AVPF has not been negotiated, then (Section 5.2). Reception of any ECN-CE marked packets SHOULD also
the RTCP ECN feedback should be sent in a compound RTCP packet result in additional early or immediate feedback packet with the
along with the regular RTCP reports. The RTP/AVPF profile SHOULD ECN feedback packet.
be negotiated where possible, since it greatly speeds up the ECN
initiation phase by ensuring that RTP senders get the earliest
possible indication that ECN works.
Determination of ECN Support: RTP is a group communication protocol, Determination of ECN Support: RTP is a group communication protocol,
where members can join and leave the group at any time. This where members can join and leave the group at any time. This
complicates the ECN initiation phase, since the sender must wait complicates the ECN initiation phase, since the sender must wait
until it believes the group membership has stabilised before it until it believes the group membership has stabilised before it
can determine if the paths to all receivers support ECN (group can determine if the paths to all receivers support ECN (group
membership changes after the ECN initiation phase has completed membership changes after the ECN initiation phase has completed
are discussed in Section 4.3). are discussed in Section 4.3).
An RTP sender shall consider the group membership to be stable An RTP sender shall consider the group membership to be stable
skipping to change at page 15, line 14 skipping to change at page 19, line 26
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 4.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 more than one other participant in the session. If other there is any other participants in the session. If other
participants are detected, the sender MUST fallback to only ECT- participants are detected, the sender MUST fallback to only ECT-
marking a small fraction of its RTP packets, while it determines marking a small fraction of its RTP packets, while it determines
if ECN can be supported following the full procedure described if ECN can be supported following the full procedure described
above. above.
Note: One use case that requires further consideration is a Note: One use case that requires further consideration is a
unicast connection with several SSRCs multiplexed onto the same unicast connection with several SSRCs multiplexed onto the same
flow (e.g. SVC video using SSRC multiplexing for the layers). flow (e.g. SVC video using SSRC multiplexing for the layers).
It is desirable to be able to rapidly negotiate ECN support for It is desirable to be able to rapidly negotiate ECN support for
such a session, but the optimisation above fails since the such a session, but the optimisation above fails since the
multiple SSRCs make it appear that this is a group multiple SSRCs make it appear that this is a group
communication scenario. It's not sufficient to check that all communication scenario. It's not sufficient to check that all
SSRCs map to a common RTCP CNAME to check if they're actually SSRCs map to a common RTCP CNAME to check if they're actually
located on the same device, because there are implementations located on the same device, because there are implementations
that use the same CNAME for different parts of a distributed that use the same CNAME for different parts of a distributed
implementation. implementation.
ECN initiation is considered to have failed at the instant when ECN initiation is considered to have failed at the instant when
any RTP session participant sends an RTCP packet that doesn't any RTP session participant sends an RTCP packet that doesn't
contain an RTCP ECN feedback report, but has an RTCP RR with an contain an RTCP ECN feedback report or ECN summary report, but has
extended RTP sequence number field that indicates that it should an RTCP RR with an extended RTP sequence number field that
have received multiple (>3) ECT marked RTP packets. This can be indicates that it should have received multiple (>3) ECT marked
due to failure to support the ECN feedback format by the receiver RTP packets. This can be due to failure to support the ECN
or some middlebox, or the loss of all ECT marked packets. Both feedback format by the receiver or some middlebox, or the loss of
indicate a lack of ECN support. all ECT marked packets. Both indicate a lack of ECN support.
The reception of RTCP ECN feedback packets that indicate greatly The reception of RTCP ECN feedback packets that indicate greatly
increased packet loss rates for ECT marked packets, compared to increased packet loss rates for ECT marked packets, compared to
non-ECT marked packets, is a strong indication of problems with non-ECT marked packets, is a strong indication of problems with
ECN support on the network path. Senders MAY consider such ECN support on the network path. Senders MAY consider such
reports as indications that they should not use ECN on the path, reports as indications that they should not use ECN on the path,
even though some ECT-marked packets to reach all receivers. even though some ECT-marked packets do reach all receivers.
The sender must also watch for cases where ECT packets has been
remarked, for example to not-ECT, either explicitly reported in an
ECN feedback packet, or implicit due to a receiver not including
the ECN feedback format in its regular report.
4.2.2. Detection of ECT using STUN with ICE 4.2.2. Detection of ECT using STUN with ICE
This section describes an OPTIONAL method that can be used to avoid This section describes an OPTIONAL method that can be used to avoid
media impact and also ensure ECN capable path prior to media media impact and also ensure ECN capable path prior to media
transmission. This method is considered in the context where the transmission. This method is considered in the context where the
session participants are using ICE [I-D.ietf-mmusic-ice] to find session participants are using ICE [I-D.ietf-mmusic-ice] to find
working connectivity. We need to use ICE rather than STUN only, as working connectivity. We need to use ICE rather than STUN only, as
the verification needs to happen from the media sender to the address the verification needs to happen from the media sender to the address
and port on which the receiver is listening. and port on which the receiver is listening.
skipping to change at page 17, line 7 skipping to change at page 21, line 33
ignored on reception. 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.
4.2.3. Leap of Faith ECT initiation method
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
recommended as the impact on both the application and the network may
be substantial. Applications may experience high packet loss rates,
this is both from dropped ECT marked packets, and the result of
driving the network into higher degrees of congestion by not being
responsive to ECN marks. The network may experience higher degrees
of congestion due to the unresponsiveness of the sender due to lost
ECN-CE marks from non-compliant remarking.
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.
Not sending any RTP packets as not-ECT in the case of non-compliant
node dropping ECT marked traffic the RTP receiver will not get any
baseline packets to ensure that it treat this SSRC as an active
sender. Thus the failure to include the sender in its RTCP sender or
receiver packets report block becomes the indicator for this case.
This is blunter than a receiver report block that indicates
explicitly how many packets actually has been lost. The sender
should be aware that in unicast or under AVPF transmission rules the
first RTCP packet may come immediately upon joining or already after
500 ms. Thus, triggering on reports without any report blocks,
cannot be done reliably on the first RTCP report received from a new
SSRC. Thus delaying detection of lack of functionality substantially
until a second report comes in.
This method is only recommended for controlled environments where the
whole path(s) between sender and receiver(s) has been built and
verified to be ECT.
4.2.4. ECN Nonce during initiation
ECN Nonce if enabled SHALL be used during initiation the same way as
ECN nonce is used under ongoing use of ECN as described in
Section 4.3.2.1.
4.3. Ongoing Use of ECN Within an RTP Session 4.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 actively sending ECT-marked RTP data packets, and that sender begins sending all RTP data packets as ECT-marked, and
its receivers begin sending ECN feedback via RTCP packets. This its receivers continue sending ECN feedback information via RTCP
section describes procedures for sending ECT-marked data, providing packets. This section describes procedures for sending ECT-marked
ECN feedback via RTCP, responding to ECN feedback, and detecting data, providing ECN feedback information via RTCP, responding to ECN
failures and misbehaving receivers. feedback information, and detecting failures and misbehaving
receivers.
4.3.1. Transmission of ECT-marked RTP Packets 4.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 choice between ECT(0) all the RTP data packets it sends as ECT. The choice between ECT(0)
and ECT(1) MUST be made randomly for each packet, and the sender MUST and ECT(1) is determined by the sender having considered the
calculate and record the ECN-nonce sum for outgoing packets [RFC3540] preferencies expressed by the "ect" parameter in the "a=ecn-capable-
rtp" attribute. 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 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 (see Section 4.4). Guidelines on the random choice of ECT values are
provided in Section 8 of [RFC3540]. 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 outgoing control messages (e.g. SHOULD NOT include ECT marks on any outgoing control messages (e.g.
STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or ZRTP STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or ZRTP
[I-D.zimmermann-avt-zrtp] control packets, that are multiplexed on [I-D.zimmermann-avt-zrtp] control packets, that are multiplexed on
the same UDP port). the same UDP port).
4.3.2. Reporting ECN Feedback via RTCP 4.3.2. Reporting ECN Feedback via RTCP
An RTP receiver that receives a packet with an ECN-CE mark, or that An RTP receiver that receives a packet with an ECN-CE mark, or that
detects a packet loss, MUST schedule the transmission of an RTCP ECN detects a packet loss, MUST schedule the transmission of an RTCP ECN
feedback packet as soon as possible to report this back to the feedback packet as soon as possible to report this back to the
sender. The feedback RTCP packet sent SHALL consist at least one ECN sender. The feedback RTCP packet sent SHALL consist at least one ECN
feedback packet (Section 5) reporting on the packets received since feedback packet (Section 5) reporting on the packets received since
skipping to change at page 17, line 39 skipping to change at page 23, line 15
[I-D.zimmermann-avt-zrtp] control packets, that are multiplexed on [I-D.zimmermann-avt-zrtp] control packets, that are multiplexed on
the same UDP port). the same UDP port).
4.3.2. Reporting ECN Feedback via RTCP 4.3.2. Reporting ECN Feedback via RTCP
An RTP receiver that receives a packet with an ECN-CE mark, or that An RTP receiver that receives a packet with an ECN-CE mark, or that
detects a packet loss, MUST schedule the transmission of an RTCP ECN detects a packet loss, MUST schedule the transmission of an RTCP ECN
feedback packet as soon as possible to report this back to the feedback packet as soon as possible to report this back to the
sender. The feedback RTCP packet sent SHALL consist at least one ECN sender. The feedback RTCP packet sent SHALL consist at least one ECN
feedback packet (Section 5) reporting on the packets received since feedback packet (Section 5) reporting on the packets received since
the last regular RTCP report, and SHOULD contain an RTCP SR or RR the last ECN feedback packet, and SHOULD contain an RTCP SR or RR
packet. The RTP/AVPF profile in early or immediate feedback mode packet. The RTP/AVPF profile in early or immediate feedback mode
SHOULD be used where possible, to reduce the interval before feedback SHOULD be used where possible, to reduce the interval before feedback
can be sent. To reduce the size of the feedback message, reduced can be sent. To reduce the size of the feedback message, reduced
size RTCP [RFC5506] MAY be used if supported by the end-points. Both size RTCP [RFC5506] MAY be used if supported by the end-points. Both
RTP/AVPF and reduced size RTCP MUST be negotiated in the session RTP/AVPF and reduced size RTCP MUST be negotiated in the session
set-up signalling before they can be used. set-up signalling before they can be used. ECN Nonce information
SHOULD NOT be included in early or immediate reports, only when
regular reports are sent.
Every time a regular compound RTCP packet is to be transmitted, the Every time a regular compound RTCP packet is to be transmitted, the
RTP receiver MUST include an ECN feedback packet as part of the RTP receiver MUST include an RTCP XR ECN summary report Section 5.2
compound packet. The ECN feedback packet must report on packets as part of the compound packet. If ECN-nonce is enabled the receiver
received during the last three reporting intervals unless that would MUST also include an RTCP XR Nonce report packet Section 5.3. It is
cause the compound RTCP packet to exceed the network MTU, in which important to configure the RTCP bandwidth (e.g. using an SDP "b="
case it MAY be reduced to cover only the last or two last reporting line) such that the bit-rate is sufficient for a usage that includes
intervals. It is important to configure the RTCP bandwidth (e.g. ECN-CE events.
using an SDP "b=" line) such that the bit-rate is sufficient for a
usage that includes ECN-CE events. Each RTCP feedback packet will
report on the ECN-CE marks received since the last report and the
current ECN nonce value.
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 reasonably timely, allowing the sender to feedback should arrive reasonably timely, allowing the sender to
react on a single or a few reports. react on a single or a few reports.
skipping to change at page 18, line 33 skipping to change at page 24, line 6
assumption that a sender will react on a few ECN-CE marks then assumption that a sender will react on a few ECN-CE marks then
suppression could be employed successfully and reduce the RTCP suppression could be employed successfully and reduce the RTCP
bandwidth usage. bandwidth usage.
In case a receiver driven congestion control algorithm is to be used In case a receiver driven congestion control algorithm is to be used
and has through signalling been agreed upon, the algorithm MAY and has through signalling been agreed upon, 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. In that case ECN feedback is only sent using regular not be done. In that case ECN feedback is only sent using regular
RTCP reports for verification purpose and in response to the RTCP reports for verification purpose and in response to the
initiation process of any new media senders as specified in initiation process ("rtp") of any new media senders as specified in
Section 4.2.1. Section 4.2.1.
4.3.2.1. ECN Nonce Reporting
ECN Nonce reporting requires both the ECN nonce sum and the sequence
numbers for packets where the ECN marking has been lost. 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 to
heavy and makes the RTCP report packet become larger than the MTU.
In that case a receiver MAY reduced to 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 4.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
skipping to change at page 20, line 34 skipping to change at page 26, line 36
In addition ECN with RTP can suffer from path changes resulting in In addition ECN with RTP can suffer from path changes resulting in
that a non ECN compliant node becomes part of the path. That node that a non ECN compliant node becomes part of the path. That node
may perform either of two actions that has effect on the ECN and may perform either of two actions that has effect on the ECN and
application functionality. The gravest is if the node drops packets application functionality. The gravest is if the node drops packets
with any ECN field values other than 00b. This can be detected by with any ECN field values other than 00b. This can be detected by
the receiver when it receives a RTCP SR packet indicating that a the receiver when it receives a RTCP SR packet indicating that 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 message or RTCP RR will indicate the situation. The the ECN feedback information or RTCP RR will indicate the situation.
other action is to remark a packet from ECT to not-ECT. That has The other action is to remark a packet from ECT to not-ECT. That has
less dire results, however, it should be detected so that ECN usage less dire results, however, it should be detected so that ECN usage
can be suspended to prevent misusing the network. can be suspended to prevent misusing the network.
ECN nonce is used as part of this solution primarily to detect non- The ECN feedback packet allows the sender to compare the number of
compliant nodes on the path. Due to its definition it will also ECT marked packets of different type with the number it actually
detect receivers attempting to cheat. We can note that it appears sent. The number of ECT packets received plus the number of CE
quite counter productive for a receiver to attempt to cheat as it marked and lost packets should correspond to the number of sent ECT
most likely will have negative impact on its media quality. marked packets. If this number doesn't agree there are two likely
reasons, a translator changing the stream or not carrying the ECN
The ECN nonce mechanism used is not exactly the same as in RFC 3540 markings forward or that some node remarks the packets. In both
due to the desire to detect also re-markings of ECT to not-ECT. Thus cases the usage of ECN is broken on the path. By tracking all the
the nonce is the 2-bit XOR sum of the previous packets Nonce value different possible ECN field values a sender can quickly detect if
and the ECN field. The initial value for the Nonce is 00b. some non-compliant behavior is happing on the path.
Thus packet losses and ECN-nonce failures are possible indication of Thus packet losses and non-matching ECN field value statistics are
issues with using ECN over the path. The next section defines both possible indication of issues with using ECN over the path. The next
sender and receiver reactions to these cases. section defines both sender and receiver reactions to these cases.
4.4.1. Fallback mechanisms 4.4.1. Fallback mechanisms
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
skipping to change at page 22, line 5 skipping to change at page 28, line 5
media from the sender only intermittently. media from the sender only intermittently.
o Load balancing devices may in worst case result in that some o Load balancing devices may in worst case result in that some
packets take a different network path then the others. packets take a different network path then the others.
o Mobility solutions that switches underlying network path in a o Mobility solutions that switches underlying network path in a
transparent way for the sender or receiver. transparent way for the sender or receiver.
o Membership changes in a multicast group. o Membership changes in a multicast group.
5. RTCP Extension for ECN feedback 4.4.2. Interpretation of ECN Summary information
One AVPF NACK Transport feedback format with the following This section contains discussion on how you can use the ECN summary
functionality is defined: report information in detecting various types of ECN path issues.
Lets start to review the information the reports provide on a per
source (SSRC) basis:
o ECN Nonce CE Counter: The number of RTP packets received so far in the session
with an ECN field set to CE (11b).
o Explicit Sequence numbers for ECN-CE marked packets 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
(10b / 01b).
o Explicit Sequence numbers for lost packets not-ECT Counter: The number of RTP packets received so far in the
session with an ECN field set to not-ECT (00b)
The usage of this feedback format called "ECN feedback format" Packet loss counter: The number of RTP packets that are expected
includes in addition to progressive reporting of ECN-CE marking using minus the number received.
Immediate or early feedback also Initiation and verification
procedures. Extended Highest Sequence number: The highest sequence number seen
when sending this report, but with additional bits, to handle
disambiguation when wrapping the RTP sequence number field.
The counters will be initiated to zero they provide value for the RTP
stream sender from the very first report. After the first report the
changes between the latest received and the previous one is
determined by simply taking the values of the latest minus the
previous one, taking field wrapping into account. This definition is
also robust to packet losses, as if one report is missing, the period
for which the information is covering becomes longer, but otherwise
equally valid.
In a perfect world the number of not-ECT received should be equal to
the number sent minus some fraction of the lost packets, and the sum
of the ECT, CE should be equal to the number ECT marked sent minus a
fraction of the lost packets. There are however two sources of
uncertainty in this, number of packet losses, and packet duplication.
Packet loss and packet duplication can change the distribution
between ECT(0), ECT(1) and not-ECT. This by having for example a ECT
(0) packet being lost, and then a ECT(1) packet being duplicated and
counted as two, thus making the ECT(1) counter become one bigger and
the ECT(0) one less than expected. To avoid these issues it is
recommended that suppression of duplicate packets are performed
before gathering this statistics.
The level of packet duplication included in the report can be
estimated from the sum over all of fields counting received packets.
A high level of packet duplication increases the insecurity in the
statistics and firm conclusions becomes more difficult and requires
clearer statics.
Detecting clearing of ECN field: If the ratio between ECT and not-
ECT transmitted in the reports has become all not-ECT or
substantially changed towards not-ECT then this is clearly
indication that the path results in clearing of the ECT field.
Dropping of ECT packets To determine if the packet drop ratio is
different between not-ECT and ECT marked transmission requires a
mix of transmitted traffic. The sender should compare if the
delivery percentage (delivered / transmitted) between ECT and not-
ECT is significantly different. Care must be taken if the number
of packets are low in either of the categories.
4.4.3. Using ECN-nonce
This document offers ECN Nonce as a method of strengthening both the
detection of failures and enable senders to verify the receiver
behavior. We note that it appears quite counter productive for a
receiver 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 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 usage is upon reception of a ECN-CE marked RTP
packet, or during the initiation procedures to speed that up. The
feedback format is also defined with reduced size RTCP [RFC5506] in
mind. In reduced size 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 the ECN functionality to verify
functionality and keep track of when CE marking does occur.
The RTCP packet starts with the common header defined by AVPF The RTCP packet starts with the common header defined by AVPF
[RFC4585] which is reproduced here for the readers information: [RFC4585] which is reproduced here for the readers information:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length | |V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender | | SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source | | SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) : : Feedback Control Information (FCI) :
: : : :
Figure 2: AVPF Feedback common header Figure 2: AVPF Feedback common header
From Figure 2 it can be determined the identity of the feedback From Figure 2 it can be determined the identity of the feedback
provider and for which RTP packet sender it applies. Below is the provider and for which RTP packet sender it applies. Below is the
feedback information format defined that is inserted as FCI for this feedback information format defined that is inserted as FCI for this
particular feedback messages that is identified with an FMT particular feedback messages that is identified with an FMT
value=TBA1. value=[TBA1].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First Sequence Number | Last Sequence Number | | Extended Highest Sequence Number | Lost packets counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|INV|RNV|Z|C|P| Reserved | Chunk 1 | | CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: More chunks if needed : | ECT (0) Counter | ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: ECN Feedback Format Figure 3: ECN Feedback Format
The FCI information for the ECN Feedback format (Figure 3) are the The FCI information for the ECN Feedback format (Figure 3) are the
following: following:
First Sequence Number: The first RTP sequence number included in the Extended Highest Sequence Number: The least significant 20-bit from
ECN nonce and base sequence number for the run length encoding. an Extended highest sequence number received value as defined by
[RFC3550]. Used to indicate for which packet this report is valid
upto.
Last Sequence Number The last RTP sequence number included in the Lost Packets Counter: The total number of RTP packets from this SSRC
ECN nonce and the run length encoding. the receiver that it expected minus the number of received, see
Section 6.4.1 of [RFC3550] for the normative definition. This
representation is done using 12-bit signed representation,
compared to 24-bit in RTCP SR or RR packets. It is important to
ensure that the wrapping is handled correctly.
CE Counter: The total number of RTP packets from this SSRC the
receiver has received since the receiver joined the RTP session
that had an ECN field value of CE. 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 total number of RTP packets from this SSRC the
receiver has received 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 has been received.
ECT (1) Counter: The total number of RTP packets from this SSRC the
receiver has received 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 has been received.
not-ECT Counter: The total number of RTP packets from this SSRC the
receiver has received 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 has been received.
Each FCI reports on a single source. 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 Lenght: The length of the report block. Used to indicate the
number of report data blocks present in the ECN summary report.
This length will 3*n, where n is the number of data blocks, i.e. 3
for one data block, 6 for two, etc.
SSRC of Media Sender: The SSRC identifying the media sender this
report is for.
CE Counter: The total number of RTP packets from this SSRC the
receiver has received since the receiver joined the RTP session
that had an ECN field value of CE. 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 has
been received.
not-ECT Counter: The total number of RTP packets from this SSRC the
receiver has received 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 has been received.
ECT (0) Counter: The total number of RTP packets from this SSRC the
receiver has received 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 has been received.
ECT (1) Counter: The total number of RTP packets from this SSRC the
receiver has received 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 has been received.
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 an Run
length encoded (RLE) bitvector that indicate which RTP sequence
numbers that wasn't included in the ECN nonce sum due to having been
lost or ECN CE marked. 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 [TBA1].
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 INV: Initial Nonce Value. Which is the value of Nonce prior to the
XOR addition of the ECN field value for the packet with RTP XOR addition of the ECN field value for the packet that start the
sequence number of "First Sequence Number". This to allow running 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 calculations and only need to save nonce values at reporting
boundaries. boundaries.
RNV: Resulting Nonce Value. The Nonce sum value resulting after RNV: Resulting Nonce Value. The Nonce sum value resulting after
having XOR the ECN field value for all packets received and not having XOR the ECN field value for all packets received and not
ECN-CE marked with the INV value. ECN-CE marked with the INV value up to the packet indicated by the
"end_seq" sequence number value.
Z: ECN Non-capable transport value seen. If set to 1, at least one begin_seq: First Sequence number this report covers.
packet within the feedback interval has had its ECN value set to
00b (Not-ECT). If set to 0, no packets within the reporting
interval has its ECN field value set to Not-ECT.
C: ECN-CE value(s) part of the feedback interval. If set to 1, at end_seq: Last RTP sequence number included in this report.
least one packet within the feedback interval was ECN-CE marked,
the sequence numbers of the packets are explicitly encoded using
chunks. If set to 0, no packets within the reporting interval had
their ECN value set to ECN-CE and no chunks are included.
P: Packet loss part of the feedback interval. If set to 1, at least chunk i: A chunk reporting on a part of bit-vector indicating if the
one packet within the feedback interval was lost in transit, the packet was excluded from the ECN Nonce due to being lost or ECN CE
sequence numbers of the packets are explicitly encoded using marked.
chunks. If set to 0, no packets within the reporting interval was
lost and no chunks are included.
Each FCI reports on a single source. Multiple sources can be The Nonce sum initial value for a new media sender (new SSRC) SHALL
reported by including multiple RTCP feedback messages in an compound be 00b. Otherwise the Initial value is the Nonce value calculated
RTCP packet. The AVPF common header indicates both the sender of the for the RTP packet with sequence number begin_seq -1. The initial
feedback message and on which stream it relates to. value for the expressed reporting interval is included in the INV
field. The receiver calculate 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.
Both the ECN-CE and packet loss information is structured as bit The Nonce reporting interval is RECOMMENDED to cover all the RTP
vector where the first bit represents the RTP packet with the packets received during the three last regular reporting intervals.
sequence number equal to the First Sequence number. The bit-vector This is to ensure that the sender will receive a report over all RTP
will contain values representing all packets up to and including the packets. Failure to deliver reports that cover all the packets may
one in the "Last Sequence Number" field. The chunk mechanism used to be interpreted as an attempt to cheat. Two additional considerations
represent the bit-vector in an efficient way may appear longer upon must be made when selecting the reporting interval. First, are the
reception if an explicit bit-vector is used as the last chunk. Bit- MTU considerations. The packet vector and its encoding into chunks
values representing packets with higher sequence number (modulo 16) results in a variable sized report. The size depends on two main
than "Last Sequence Number" are not valid and SHALL be ignored. 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.
The RTP sequence number can easily wrap and that needs to be Secondly, the RTP sequence number can easily wrap and that needs to
considered when handling them. The report SHALL NOT report on more be considered when they are handed. The report SHALL NOT report on
than 32768 consecutive packets. The last sequence number is the more than 32768 consecutive packets. The last sequence number is the
extended sequence number that is equal too or smaller (less than extended sequence number that is equal too or smaller (less than
65535 packets) than the value present in the Receiver Reports 65535 packets) than the value present in the Receiver Reports
"extended highest sequence number received" field. The "first "extended highest sequence number received" field. The "first
sequence number" value is thus is as an extended sequence number sequence number" value is thus an extended sequence number which is
smaller than the "last sequence number". If there is a wrap between smaller than the "last sequence number". If there is a wrap between
the first sequence number and the last, i.e. First sequence number > the first sequence number and the last, i.e. First sequence number >
Last sequence number (seen as 16-bit unsigned integers), then the Last sequence number (seen as 16-bit unsigned integers), then the
wrap needs to included in the calculation. wrap needs to included in the calculation. If an application is
having these issues, the frequency of regular RTCP reporting should
The ECN-CE bit-vector uses values of 1 to represent that the be modified by ensuring that the application chooses appropriate
corresponding packet was marked as ECN-CE, all other ECN values are settings for the minimum RTCP reporting interval parameters.
represented as a 0. The packet loss bit vector uses value of 1 to
represent that the corresponding packet was received and a value of 0
to represent loss.
The produced bit-vectors are encoded using chunks. The chunks are Both the ECN-CE and packet loss information is structured as bit
any of the three types defined in [RFC3611], Run Length Chunk vectors where the first bit represents the RTP packet with the
(Section 4.1.1 of [RFC3611]), Bit Vector Chunk (Section 4.1.2 of sequence number equal to the First Sequence number. The bit-vector
[RFC3611]), or Terminating Null Chunk (Section 4.1.3 of [RFC3611]). will contain values representing all packets up to and including the
In the chunk part of the FCI at least one chunk MUST be included to one in the "end_seq" field. The chunk mechanism used to represent
achieve 32-bit word alignment. The C and P bits are used to indicate the bit-vector in an efficient way may appear longer upon reception
the inclusion of two different information reports in the feedback if an explicit bit-vector is used as the last chunk. Bit-values
message. When both C and P are sent, the chunks reporting if ECN-CE representing packets with higher sequence number (modulo 16) than
was set SHALL be sent first, followed by one Terminating Null chunk "end_seq" are not valid and SHALL be ignored.
followed by the chunks reporting on which packets where lost,
possibly followed by one terminating null chunk to achieve 32-bit
word alignment. If only one of the C and P bits are set the chunks
reports on only that information, the last chunk MAY be a Terminating
Null chunk if necessary to achieve 32-bit word alignment. If none of
the C and P bits are set, only a single Terminating Null Chunk is
included.
(tbd: We also need to register a regular RTCP packet format The produced bit-vector is encoded using chunks. The chunks are any
containing the same information as the AVPF NACK feedback format, so of the three types defined in [RFC3611], Run Length Chunk (Section
that it can be used with in regular compound RTCP packets.) 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 6. Processing RTCP ECN Feedback in RTP Translators and Mixers
RTP translators and mixers that support ECN feedback are required to RTP translators and mixers that support ECN feedback are required to
process, and potentially modify or generate, RTCP packets for the process, and potentially modify or generate, RTCP packets for the
translated and/or mixed streams. translated and/or mixed streams.
6.1. Fragmentation and Reassembly in Translators 6.1. Fragmentation and Reassembly in Translators
An RTP translator may fragment or reassemble RTP data packets without An RTP translator may fragment or reassemble RTP data packets without
skipping to change at page 26, line 10 skipping to change at page 38, line 26
marks to the outgoing packets. This section describes how RTCP is marks to the outgoing packets. This section describes how RTCP is
processed in RTP mixers, and how that interacts with ECN feedback. processed in RTP mixers, and how that interacts with ECN feedback.
(tbd: complete this section) (tbd: complete this section)
7. Implementation considerations 7. Implementation considerations
To allow the use of ECN with RTP over UDP, the RTP implementation To allow the use of ECN with RTP over UDP, the RTP implementation
must be able to set the ECT bits in outgoing UDP datagrams, and must must be able to set the ECT bits in outgoing UDP datagrams, and must
be able to read the value of the ECT bits on received UDP datagrams. be able to read the value of the ECT bits on received UDP datagrams.
The standard Berkeley sockets API predates 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 8. 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 8.1. SDP Attribute Registration
skipping to change at page 26, line 46 skipping to change at page 39, line 15
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 8.2. AVPF Transport Feedback Message
A new RTCP Transport feedback message needs a FMT code point A new RTCP Transport feedback message needs a FMT code point
assigned. ... assigned. ...
8.3. STUN attribute 8.3. RTCP XR Report blocks
Two new RTCP XR report blocks needs to be assigned block type codes.
8.4. STUN attribute
A new STUN attribute in the Comprehension-optional range needs to be A new STUN attribute in the Comprehension-optional range needs to be
assigned... assigned...
8.4. ICE Option 8.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 9. 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
congestion response. 2. Ensure that the sender disable the usage congestion response. 2. Ensure that the sender disable the usage
of ECN by reporting failures to receive ECN by setting the Z bit of ECN by reporting failures to receive ECN by changing the
or changing the ECN nonce field. Both Issues, can also be counter fields. The Issue, can also be accomplished by injecting
accomplished by injecting false RTCP packets to the media sender. false RTCP packets to the media sender. Reporting a lot of CE
Reporting a lot of CE marked traffic is likely the more efficient marked traffic is likely the more efficient denial of service tool
denial of service tool as that may likely force the application to as that may likely force the application to use lowest possible
use lowest possible bit-rates. The prevention against an external bit-rates. The prevention against an external threat is to
threat is to integrity protect the RTCP feedback information and integrity protect the RTCP feedback information and authenticate
authenticate the sender of it. the sender of it.
Information leakage: The ECN feedback mechanism exposes the Information leakage: The ECN feedback mechanism exposes the
receivers perceived packet loss, what packets it considers to be receivers perceived packet loss, what packets it considers to be
ECN-CE marked and its calculation of the ECN-none. This is mostly ECN-CE marked and its calculation of the ECN-none. This is mostly
not considered sensitive information. If considered sensitive the not considered sensitive information. If considered sensitive the
RTCP feedback shall be encrypted. RTCP feedback shall be encrypted.
Changing the ECN bits An on-path attacker that see the RTP packet Changing the ECN bits An on-path attacker that see the RTP packet
flow from sender to receiver and who has the capability to change flow from sender to receiver and who has the capability to change
the packets can rewrite ECT into ECN-CE thus forcing the sender or the packets can rewrite ECT into ECN-CE thus forcing the sender or
skipping to change at page 29, line 41 skipping to change at page 42, line 14
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 [RFC3851] would be used. However, with the SDP ideally S/MIME [RFC3851] 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] [I-D.ietf-sip-sips] to at least SIPS (SIP over TLS) [RFC3261] [I-D.ietf-sip-sips] to at least
accomplish hop-by-hop protection. accomplish hop-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. References 10. Examples of SDP Signalling
10.1. Normative References (tbd)
11. Open Issues
As this draft is under development some known open issues exist and
are collected here. Please consider them and provide input.
1. Packet duplication. Packet duplication results in uncertainties
in the ECN summary counters. At the same time suppressing
duplicates and ignoring their ECN marks may also be problematic.
Consider the case when a packet get duplicated prior to a
congestion point and one version arrives with a ECT mark, and the
other with CE mark. What to report?
2. The negotiation and directionality attribute is going to need
some consideration for multi-party sessions when readonly
capability might be sufficient to enable ECN for all incomming
streams. However, it would beneficial to know if no potential
sender support setting ECN.
3. Consider initiation optimizations that allows for multi SSRC
sender nodes to still have rapid usage of ECN.
4. Feedback suppression for ECN-CE, both for groups, and in case an
additional CE mark arrives within a RTT at the receiver.
12. References
12.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
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control
Protocol Extended Reports (RTCP XR)", RFC 3611, Protocol Extended Reports (RTCP XR)", RFC 3611,
November 2003. November 2003.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008.
[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.
10.2. Informative References 12.2. Informative References
[I-D.ietf-avt-rtcpssm] [I-D.ietf-avt-rtcpssm]
Schooler, E., Ott, J., and J. Chesterfield, "RTCP Schooler, E., Ott, J., and J. Chesterfield, "RTCP
Extensions for Single-Source Multicast Sessions with Extensions for Single-Source Multicast Sessions with
Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in Unicast Feedback", draft-ietf-avt-rtcpssm-18 (work in
progress), March 2009. progress), March 2009.
[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.
skipping to change at page 30, line 46 skipping to change at page 44, line 4
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-sip-sips] [I-D.ietf-sip-sips]
Audet, F., "The use of the SIPS URI Scheme in the Session Audet, F., "The use of the SIPS URI Scheme in the Session
Initiation Protocol (SIP)", draft-ietf-sip-sips-09 (work Initiation Protocol (SIP)", draft-ietf-sip-sips-09 (work
in progress), November 2008. in progress), November 2008.
[I-D.ietf-tsvwg-ecn-tunnel] [I-D.ietf-tsvwg-ecn-tunnel]
Briscoe, B., "Tunnelling of Explicit Congestion Briscoe, B., "Tunnelling of Explicit Congestion
Notification", draft-ietf-tsvwg-ecn-tunnel-02 (work in Notification", draft-ietf-tsvwg-ecn-tunnel-03 (work in
progress), March 2009. progress), July 2009.
[I-D.zimmermann-avt-zrtp] [I-D.zimmermann-avt-zrtp]
Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media
Path Key Agreement for Secure RTP", Path Key Agreement for Secure RTP",
draft-zimmermann-avt-zrtp-15 (work in progress), draft-zimmermann-avt-zrtp-15 (work in progress),
March 2009. March 2009.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit
Congestion Notification (ECN) Signaling with Nonces", Congestion Notification (ECN) Signaling with Nonces",
RFC 3540, June 2003. RFC 3540, June 2003.
[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and
Video Conferences with Minimal Control", STD 65, RFC 3551,
July 2003.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, March 2004. RFC 3711, March 2004.
[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004. RFC 3851, July 2004.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
skipping to change at page 31, line 47 skipping to change at page 45, line 10
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey,
"Extended RTP Profile for Real-time Transport Control "Extended RTP Profile for Real-time Transport Control
Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585,
July 2006. July 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", [RFC4960] Stewart, R., "Stream Control Transmission Protocol",
RFC 4960, September 2007. RFC 4960, September 2007.
[RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for
Real-time Transport Control Protocol (RTCP)-Based Feedback
(RTP/SAVPF)", RFC 5124, February 2008.
[RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size
Real-Time Transport Control Protocol (RTCP): Opportunities Real-Time Transport Control Protocol (RTCP): Opportunities
and Consequences", RFC 5506, April 2009. and Consequences", RFC 5506, April 2009.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
Ericsson Ericsson
Farogatan 6 Farogatan 6
SE-164 80 Kista SE-164 80 Kista
skipping to change at line 1498 skipping to change at page 46, line 4
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 Department of Computing Science
Glasgow G12 8QQ Glasgow G12 8QQ
United Kingdom United Kingdom
Email: csp@csperkins.org Email: csp@csperkins.org
Piers O'Hanlon
University College London
Computer Science Department
Gower Street
London WC1E 6BT
United Kingdom
Email: p.ohanlon@cs.ucl.ac.uk
Ken Carlberg
G11
1600 Clarendon Blvd
Arlington VA
USA
Email: carlberg@g11.org.uk
 End of changes. 102 change blocks. 
356 lines changed or deleted 961 lines changed or added

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