One document matched: draft-ietf-avtcore-ecn-for-rtp-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1112 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1112.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc3168 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3168.xml">
<!ENTITY rfc3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY rfc3611 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3611.xml">
<!ENTITY rfc5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5234.xml">
<!ENTITY rfc5245 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY rfc5348 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5348.xml">
<!ENTITY rfc5389 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5389.xml">
<!ENTITY icereg SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mmusic-ice-options-registry.xml">
<!ENTITY rfc2762 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2762.xml">
<!ENTITY rfc2974 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2974.xml">
<!ENTITY rfc3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY rfc3264 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3264.xml">
<!ENTITY rfc3540 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3540.xml">
<!ENTITY rfc3551 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3551.xml">
<!ENTITY rfc3569 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3569.xml">
<!ENTITY rfc3711 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY rfc5751 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5751.xml">
<!ENTITY rfc4301 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY rfc4340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4340.xml">
<!ENTITY rfc4347 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4347.xml">
<!ENTITY rfc4566 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4566.xml">
<!ENTITY rfc4585 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4585.xml">
<!ENTITY rfc4588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4588.xml">
<!ENTITY rfc4607 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4607.xml">
<!ENTITY rfc4960 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4960.xml">
<!ENTITY rfc5124 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5124.xml">
<!ENTITY rfc5506 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5506.xml">
<!ENTITY rfc5630 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5630.xml">
<!ENTITY rfc5760 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5760.xml">
<!ENTITY rfc6189 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6189.xml">
<!ENTITY no-op SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-avt-rtp-no-op.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="2"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-avtcore-ecn-for-rtp-04"
ipr="trust200902">
<front>
<title abbrev="ECN for RTP over UDP/IP">Explicit Congestion Notification
(ECN) for RTP over UDP</title>
<author fullname="Magnus Westerlund" initials="M." surname="Westerlund">
<organization>Ericsson</organization>
<address>
<postal>
<street>Farogatan 6</street>
<city>SE-164 80 Kista</city>
<country>Sweden</country>
</postal>
<phone>+46 10 714 82 87</phone>
<email>magnus.westerlund@ericsson.com</email>
</address>
</author>
<author fullname="Ingemar Johansson" initials="I." surname="Johansson">
<organization>Ericsson</organization>
<address>
<postal>
<street>Laboratoriegrand 11</street>
<city>SE-971 28 Lulea</city>
<country>SWEDEN</country>
</postal>
<phone>+46 73 0783289</phone>
<email>ingemar.s.johansson@ericsson.com</email>
</address>
</author>
<author fullname="Colin Perkins" initials="C. " surname="Perkins">
<organization>University of Glasgow</organization>
<address>
<postal>
<street>School of Computing Science</street>
<city>Glasgow</city>
<code>G12 8QQ</code>
<country>United Kingdom</country>
</postal>
<email>csp@csperkins.org</email>
</address>
</author>
<author fullname="Piers O'Hanlon" initials="P." surname="O'Hanlon">
<organization abbrev="UCL">University College London</organization>
<address>
<postal>
<street>Computer Science Department</street>
<street>Gower Street</street>
<city>London</city>
<code>WC1E 6BT</code>
<country>United Kingdom</country>
</postal>
<email>p.ohanlon@cs.ucl.ac.uk</email>
</address>
</author>
<author fullname="Ken Carlberg" initials="K." surname="Carlberg">
<organization>G11</organization>
<address>
<postal>
<street>1600 Clarendon Blvd</street>
<city>Arlington</city>
<code>VA</code>
<country>USA</country>
</postal>
<email>carlberg@g11.org.uk</email>
</address>
</author>
<date day="11" month="July" year="2011" />
<abstract>
<t>This memo specifies how Explicit Congestion Notification (ECN) can be
used with the Real-time Transport Protocol (RTP) running over UDP, using
RTP Control Protocol (RTCP) as a feedback mechanism. It defines a new
RTCP Extended Report (XR) block for periodic ECN feedback, a new RTCP
transport feedback message for timely reporting of congestion events,
and a Session Traversal Utilities for NAT (STUN) extension used in the
optional initialization method using Interactive Connectivity
Establishment (ICE). Signalling and procedures for negotiation of
capabilities and initialization methods are also defined.</t>
</abstract>
</front>
<middle>
<section anchor="sec-intro" title="Introduction">
<t>This memo outlines how Explicit Congestion Notification (ECN) <xref
target="RFC3168"></xref> can be used for <xref
target="RFC3550">Real-time Transport Protocol (RTP)</xref> flows running
over UDP/IP which use RTP Control Protocol (RTCP) as a feedback
mechanism. The solution consists of feedback of ECN congestion
experienced markings to the sender using RTCP, verification of ECN
functionality end-to-end, and procedures for how to initiate ECN usage.
Since the initiation process has some dependencies on the signalling
mechanism used to establish the RTP session, a specification for
signalling mechanisms using <xref target="RFC4566">Session Description
Protocol (SDP)</xref> is included.</t>
<t>ECN is getting attention as a method to minimise the impact of
congestion on real-time multimedia traffic. The use of ECN provides a
way for the network to send a congestion control signal to a media
transport without having to impair the media. Unlike packet loss, ECN
signals unambiguously indicate congestion to the transport as quickly as
feedback delays allow, and without confusing congestion with losses that
might have occurred for other reasons such as transmission errors,
packet-size errors, routing errors, badly implemented middleboxes,
policy violations and so forth.</t>
<t>The introduction of ECN into the Internet requires changes to both
the network and transport layers. At the network layer, IP forwarding
has to be updated to allow routers to mark packets, rather than
discarding them in times of congestion <xref target="RFC3168"></xref>.
In addition, transport protocols have to be modified to inform the
sender that ECN marked packets are being received, so it can respond to
the congestion. The <xref target="RFC3168">Transmission Control Protocol
(TCP)</xref>, <xref target="RFC4960">Stream Control Transmission
Protocol (SCTP)</xref> and <xref target="RFC4340">Datagram Congestion
Control Protocol (DCCP)</xref> have been updated to support ECN, but to
date there is no specification how UDP-based transports, such as <xref
target="RFC3550"> RTP</xref>, can use ECN. This is due to the lack of
feedback mechanisms directly in UDP. Instead the signaling control
protocol on top of UDP needs to provide that feedback. For RTP that
feedback is provided by RTCP.</t>
<t>The remainder of this memo is structured as follows. We start by
describing the conventions, definitions and acronyms used in this memo
in <xref target="sec-2119"></xref>, and the design rationale and
applicability in <xref target="sec-rationale"></xref>. <xref
target="sec-overview"></xref> gives an overview of how ECN is used with
RTP over UDP. RTCP extensions for ECN feedback are defined in <xref
target="sec-rtcp-ecn"></xref>, and SDP signalling extensions in <xref
target="sec-sdp-ext"></xref>. The details of how ECN is used with RTP
over UDP are defined in <xref target="sec-definition"></xref>. In <xref
target="sec-rtcp-translator-mixer"></xref> we describe how ECN is
handled in RTP translators and mixers. <xref target="sec-impl"></xref>
discusses some implementation considerations, <xref
target="sec-iana"></xref> lists IANA considerations, and <xref
target="sec-security"></xref> discusses security considerations.</t>
</section>
<section anchor="sec-2119" title="Conventions, Definitions and Acronyms">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in <xref
target="RFC2119"> RFC 2119</xref>.</t>
<t>Abbreviations and Definitions: <list style="hanging">
<t hangText="Sender:">A sender of RTP packets carrying an encoded
media stream. The sender can change how the media transmission is
performed by varying the media coding or packetisation. It is one
end-point of the ECN control loop.</t>
<t hangText="Receiver:">A receiver of RTP packets with the intention
to consume the media stream. It sends RTCP feedback on the received
stream. It is the other end-point of the ECN control loop.</t>
<t hangText="ECN Capable Host:">A sender or receiver of a media
stream that is capable of setting and/or processing ECN marks.</t>
<t hangText="ECN Capable Transport (ECT):">A transport flow where
both sender and receiver are ECN capable hosts. Packets sent by an
ECN Capable Transport will be marked as ECT(0) or ECT(1) on
transmission. See <xref target="RFC3168"></xref> for the definition
of the ECT(0) and ECT(1) marks.</t>
<t hangText="ECN-CE:">ECN Congestion Experienced mark (see <xref
target="RFC3168"></xref>).</t>
<t hangText="ECN Capable Packets:">Packets with ECN mark set to
either ECT(0), ECT(1) or ECN-CE.</t>
<t hangText="Not-ECT packets:">Packets that are not sent by an ECN
capable transport, and are not ECN-CE marked.</t>
<t hangText="ECN Oblivious Relay:">A router or middlebox that treats
ECN Capable Packets no differently from Not-ECT packets.</t>
<t hangText="ECN Capable Queue:">A queue that supports ECN-CE
marking of ECN-Capable Packets to indicate congestion.</t>
<t hangText="ECN Blocking Middlebox:">A middlebox that discards
ECN-Capable Packets.</t>
<t hangText="ECN Reverting Middlebox:">A middlebox that changes
ECN-Capable Packets to Not-ECT packets by removing the ECN mark.</t>
</list></t>
<t>Note that RTP mixers or translators that operate in such a manner
that they terminate or split the ECN control loop will take on the role
of receivers or senders. This is further discussed in <xref
target="sec-applicability"></xref>.</t>
</section>
<section anchor="sec-rationale"
title="Discussion, Requirements, and Design Rationale">
<t>ECN has been specified for use with <xref
target="RFC3168">TCP</xref>, <xref target="RFC4960">SCTP</xref>, and
<xref target="RFC4340">DCCP</xref> transports. These are all unicast
protocols which negotiate the use of ECN during the initial connection
establishment handshake (supporting incremental deployment, and checking
if ECN marked packets pass all middleboxes on the path). ECN-CE marks
are immediately echoed back to the sender by the receiving end-point
using an additional bit in feedback messages, and the sender then
interprets the mark as equivalent to a packet loss for congestion
control purposes.</t>
<t>If RTP is run over TCP, SCTP, or DCCP, it can use the native ECN
support provided by those protocols. This memo does not concern itself
further with these use cases. However, RTP is more commonly run over
UDP. This combination does not currently support ECN, and we observe
that it has significant differences from the other transport protocols
for which ECN has been specified. These include: <list style="hanging">
<t hangText="Signalling:">RTP relies on separate signalling
protocols to negotiate parameters before a session can be created,
and doesn't include an in-band handshake or negotiation at session
set-up time (i.e., there is no equivalent to the TCP three-way
handshake in RTP).</t>
<t hangText="Feedback:">RTP does not explicitly acknowledge receipt
of datagrams. Instead, the RTP Control Protocol (RTCP) provides
reception quality feedback, and other back channel communication,
for RTP sessions. The feedback interval is generally on the order of
seconds, rather than once per network RTT (although the RTP/AVPF
profile <xref target="RFC4585"></xref> allows more rapid feedback in
most cases). RTCP is also very much oriented around counting
packets, which makes byte counting congestion algorithms difficult
to utilize.</t>
<t hangText="Congestion Response:">While it is possible to adapt the
transmission of many audio/visual streams in response to network
congestion, and such adaptation is required by <xref
target="RFC3550"></xref>, the dynamics of the congestion response
may be quite different to those of TCP or other transport
protocols.</t>
<t hangText="Middleboxes:">The RTP framework explicitly supports the
concept of mixers and translators, which are middleboxes that are
involved in media transport functions.</t>
<t hangText="Multicast:">RTP is explicitly a group communication
protocol, and was designed from the start to support IP multicast
(primarily <xref target="RFC1112">Any Source Multicast (ASM)</xref>,
although a recent extension supports <xref target="RFC3569">Source
Specific Multicast (SSM)</xref> with unicast feedback <xref
target="RFC5760"></xref>).</t>
<t hangText="Application Awareness:">When ECN support is provided
within the transport protocol, the ability of the application to
react to congestion is limited, since it has little visibility into
the transport layer. By adding support of ECN to RTP using RTCP
feedback, the application is made aware of congestion, allowing a
wider range of reactions in response to that loss.</t>
<t hangText="Counting vs Detecting Congestion:">TCP and the
protocols derived from it are mainly designed to respond the same
whether they experience a burst of congestion indications within one
RTT or just one. Whereas real-time applications may be concerned
with the amount of congestion experienced, whether it is distributed
smoothly or in bursts. When feedback of ECN was added to TCP <xref
target="RFC3168"></xref>, the receiver was designed to flip the echo
congestion experienced (ECE) flag to 1 for a whole RTT then flop it
back to zero. Whereas ECN feedback in RTCP will need to report a
count of how much congestion has been experienced within an RTCP
reporting period, irrespective of round trip times.</t>
</list>These differences will significantly alter the shape of ECN
support in RTP-over-UDP compared to ECN support in TCP, SCTP, and DCCP,
but do not invalidate the need for ECN support.</t>
<t>ECN support is more important for RTP sessions than, for instance, is
the case for TCP. This is because the impact of packet loss in real-time
audio-visual media flows is highly visible to users. Effective ECN
support for RTP flows running over UDP will allow real-time audio-visual
applications to respond to the onset of congestion before routers are
forced to drop packets, allowing those applications to control how they
reduce their transmission rate, and hence media quality, rather than
responding to, and trying to conceal the effects of unpredictable packet
loss. Furthermore, widespread deployment for ECN and active queue
management in routers, should it occur, can potentially reduce
unnecessary queueing delays in routers, lowering the round-trip time and
benefiting interactive applications of RTP, such as voice telephony.</t>
<section title="Requirements">
<t>Considering ECN, transport protocols supporting ECN, and RTP based
applications one can create a set of requirements that must be
satisfied to at least some degree if ECN is to used by RTP over UDP.
<list style="symbols">
<t>REQ 1: A mechanism MUST exist to negotiate and initiate the use
of ECN for RTP/UDP/IP sessions so that an RTP sender will not send
packets with ECT in the IP header unless it knows that all
potential receivers will understand any ECN-CE indications they
might receive.</t>
<t>REQ 2: A mechanism MUST exist to feed back the reception of any
packets that are ECN-CE marked to the packet sender.</t>
<t>REQ 3: The provided mechanism SHOULD minimise the possibility
of cheating (either by the sender or receiver).</t>
<t>REQ 4: Some detection and fallback mechanism SHOULD exist to
avoid loss of communication due to the attempted usage of ECN in
case an intermediate node clears ECT or drops packets that are ECT
marked.</t>
<t>REQ 5: Negotiation of ECN SHOULD NOT significantly increase the
time taken to negotiate and set-up the RTP session (an extra RTT
before the media can flow is unlikely to be acceptable for some
use cases).</t>
<t>REQ 6: Negotiation of ECN SHOULD NOT cause media clipping at
the start of a session.</t>
</list></t>
<t>The following sections describes how these requirements can be met
for RTP over UDP.</t>
</section>
<section anchor="sec-applicability" title="Applicability">
<t>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
support in all elements of the network path(s) traversed. RTP is used
in a heterogeneous range of network environments and topologies, with
various different signalling protocols. The mechanisms defined here
make it possible to verify support for ECN in each of these
environments, and irrespective of the topology.</t>
<t>Due to the need for each RTP sender that intends to use ECN with
RTP to track all participants in the RTP session, the sub-sampling of
the group membership as specified by <xref target="RFC2762">"Sampling
of the Group Membership in RTP"</xref> MUST NOT be used.</t>
<t>The use of ECN is further dependent on a capability of the RTP
media flow to react to congestion signalled by ECN marked packets.
Depending on the application, media codec, and network topology, this
adaptation can occur in various forms and at various nodes. As an
example, the sender can change the media encoding, or the receiver can
change the subscription to a layered encoding, or either reaction can
be accomplished by a transcoding middlebox. RFC 5117 identifies seven
topologies in which RTP sessions may be configured, and which may
affect the ability to use ECN: <list style="hanging">
<t hangText="Topo-Point-to-Point:">This is a standard unicast
flow. ECN may be used with RTP in this topology in an analogous
manner to its use with other unicast transport protocols, with
RTCP conveying ECN feedback messages.</t>
<t hangText="Topo-Multicast:">This is either an any source
multicast (ASM) group <xref target="RFC3569"></xref> with
potentially several active senders and multicast RTCP feedback, or
a source specific multicast (SSM) group <xref
target="RFC4607"></xref> with a single sender and unicast RTCP
feedback from receivers. RTCP is designed to scale to large group
sizes while avoiding feedback implosion (see Section 6.2 of <xref
target="RFC3550"></xref>, <xref target="RFC4585"></xref>, and
<xref target="RFC5760"></xref>), and can be used by a sender to
determine if all its receivers, and the network paths to those
receivers, support ECN (see <xref
target="sec-initiation"></xref>). It is somewhat more difficult to
determine if all network paths from all senders to all receivers
support ECN. Accordingly, we allow ECN to be used by an RTP sender
using multicast UDP provided the sender has verified that the
paths to all its known receivers support ECN, and irrespective of
whether the paths from other senders to their receivers support
ECN ("all its known receivers" are all the SSRCs that the RTP
sender has received RTP or RTCP from the last five reporting
intervals, i.e., they have not timed out). Note that group
membership may change during the lifetime of a multicast RTP
session, potentially introducing new receivers that are not ECN
capable or have a path that doesn't support ECN. Senders must use
the mechanisms described in <xref target="sec-ecn-failure"></xref>
to check that all receivers, and the network paths traversed to
reach those receivers, continue to support ECN, and they need to
fallback to non-ECN use if any receivers join that do not.</t>
<t hangText="Topo-Translator:">An RTP translator is an RTP-level
middlebox that is invisible to the other participants in the RTP
session (although it is usually visible in the associated
signalling session). There are two types of RTP translator: those
that do not modify the media stream, and are concerned with
transport parameters, for example a multicast to unicast gateway;
and those that do modify the media stream, for example transcoding
between different media codecs. A single RTP session traverses the
translator, and the translator must rewrite RTCP messages passing
through it to match the changes it makes to the RTP data packets.
A legacy, ECN-unaware, RTP translator is expected to ignore the
ECN bits on received packets, and to set the ECN bits to not-ECT
when sending packets, so causing ECN negotiation on the path
containing the translator to fail (any new RTP translator that
does not wish to support ECN may do so similarly). An ECN aware
RTP translator may act in one of three ways: <list style="symbols">
<t>If the translator does not modify the media stream, it
should copy the ECN bits unchanged from the incoming to the
outgoing datagrams, unless it is overloaded and experiencing
congestion, in which case it may mark the outgoing datagrams
with an ECN-CE mark. Such a translator passes RTCP feedback
unchanged. See <xref
target="sec-rtcp-trn-translator"></xref>.</t>
<t>If the translator modifies the media stream to combine or
split RTP packets, but does not otherwise transcode the media,
it must manage the ECN bits in a way analogous to that
described in Section 5.3 of <xref target="RFC3168"></xref>,
see <xref target="sec-rtcp-ecn-translator"></xref> for
details.</t>
<t>If the translator is a media transcoder, or otherwise
modifies the content of the media stream, the output RTP media
stream may have radically different characteristics than the
input RTP media stream. Each side of the translator must then
be considered as a separate transport connection, with its own
ECN processing. This requires the translator interpose itself
into the ECN negotiation process, effectively splitting the
connection into two parts with their own negotiation. Once
negotiation has been completed, the translator must generate
RTCP ECN feedback back to the source based on its own
reception, and must respond to RTCP ECN feedback received from
the receiver(s) (see <xref
target="sec-rtcp-ecn-synthetic"></xref>).</t>
</list> It is recognised that ECN and RTCP processing in an RTP
translator that modifies the media stream is non-trivial.</t>
<t hangText="Topo-Mixer:">A mixer is an RTP-level middlebox that
aggregates multiple RTP streams, mixing them together to generate
a new RTP stream. The mixer is visible to the other participants
in the RTP session, and is also usually visible in the associated
signalling session. The RTP flows on each side of the mixer are
treated independently for ECN purposes, with the mixer generating
its own RTCP ECN feedback, and responding to ECN feedback for data
it sends. Since unicast transport between the mixer and any
end-point are treated independently, it would seem reasonable to
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, if
this is desired. See <xref target="sec-rtcp-mixer"></xref> for
details in how mixers should process ECN.</t>
<t hangText="Topo-Video-switch-MCU:">A video switching MCU
receives several RTP flows, but forwards only one of those flows
onwards to the other participants at a time. The flow that is
forwarded changes during the session, often based on voice
activity. Since only a subset of the RTP packets generated by a
sender are forwarded to the receivers, a video switching MCU can
break ECN negotiation (the success of the ECN negotiation may
depend on the voice activity of the participant at the instant the
negotiation takes place - shout if you want ECN). It also breaks
congestion feedback and response, since RTP packets are dropped by
the MCU depending on voice activity rather than network
congestion. This topology is widely used in legacy products, but
is NOT RECOMMENDED for new implementations and SHALL NOT be used
with ECN.</t>
<t hangText="Topo-RTCP-terminating-MCU:">In this scenario, each
participant runs an RTP point-to-point session between itself and
the MCU. Each of these sessions is treated independently for the
purposes of ECN and RTCP feedback, potentially with some using ECN
and some not.</t>
<t hangText="Topo-Asymmetric:">It is theoretically possible to
build a middlebox 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 problematic and it is so easy to get the RTCP
processing wrong, that it is NOT RECOMMENDED to implement this
topology."</t>
</list> These topologies may be combined within a single RTP
session.</t>
<t>The ECN mechanism defined in this memo is applicable to both sender
and receiver controlled congestion algorithms. The mechanism ensures
that both senders and receivers will know about ECN-CE markings and
any packet losses. Thus the actual decision point for the congestion
control is not relevant. This is a great benefit as the rate of an RTP
session can be varied in a number of ways, for example a unicast media
sender might use TFRC <xref target="RFC5348"></xref> or some other
algorithm, while a multicast session could use a sender based scheme
adapting to the lowest common supported rate, or a receiver driven
mechanism using layered coding to support more heterogeneous
paths.</t>
<t>To ensure timely feedback of ECN-CE marked packets when needed,
this mechanism requires support for the RTP/AVPF profile <xref
target="RFC4585"></xref> or any of its derivatives, such as RTP/SAVPF
<xref target="RFC5124"></xref>. The standard RTP/AVP profile <xref
target="RFC3551"></xref> 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.</t>
</section>
<section title="Interoperability">
<t>The interoperability requirements for this specification are that
there is at least one common interoperability point for all
implementations. Since initialization using RTP and RTCP (<xref
target="sec-rtp-init-ecn"></xref>) is the one method that works in all
cases, although is not optimal for all uses, it is selected as
mandatory to implement this initialisation method. This method
requires both the RTCP XR extension and the ECN feedback format, which
require the RTP/AVPF profile to ensure timely feedback.</t>
<t>When one considers all the uses of ECN for RTP it is clear that
there exist congestion control mechanisms that are receiver driven
<xref target="sec-congestion">only</xref>. These congestion control
mechanism do not require timely feedback of congestion events to the
sender. If such a congestion control mechanism is combined with an
initialization method that also doesn't require timely feedback using
RTCP, like the leap of faith or the ICE based method then neither the
ECN feedback format nor the RTP/AVPF profile would appear to be
needed. However, fault detection can be greatly improved by using
receiver side detection (<xref target="sec-fallback"></xref>) and
early reporting of such cases using the ECN feedback mechanism.</t>
<t>For interoperability we mandate the implementation of the RTP/AVPF
profile, with both RTCP extensions and the necessary signalling to
support a common operations mode. This specification recommends the
use of RTP/AVPF in all cases as negotiation of the common
interoperability point requires RTP/AVPF, mixed negotiation of RTP/AVP
and RTP/AVPF depending on other SDP attributes in the same media block
is difficult, and the fact that fault detection can be improved when
using RTP/AVPF.</t>
<t>The use of the ECN feedback format is also recommended, but cases
exist where its use is not required due to no need for timely
feedback. These will be explicitly noted using the term "no timely
feedback required", and generally occur in combination with receiver
driven congestion control, and with the leap-of-faith and ICE-based
initialization methods. We also note that any receiver driven
congestion control solution that still requires RTCP for signalling of
any adaptation information to the sender will still require RTP/AVPF
for timeliness.</t>
</section>
</section>
<section anchor="sec-overview"
title="Overview of Use of ECN with RTP/UDP/IP">
<t>The solution for using ECN with RTP over UDP/IP consists of four
different pieces that together make the solution work:</t>
<t><list style="numbers">
<t>Negotiation of the capability to use ECN with RTP/UDP/IP</t>
<t>Initiation and initial verification of ECN capable transport</t>
<t>Ongoing use of ECN within an RTP session</t>
<t>Handling of dynamic behavior through failure detection,
verification and fallback</t>
</list></t>
<t>Before an RTP session can be created, a signalling protocol is used
to discover the other participants and negotiate or configure session
parameters (see <xref target="sec-signalling"></xref>). One of the
parameters that must be agreed is the capability of a participant to
support ECN. Note that all participants having the capability of
supporting ECN does not necessarily imply that ECN is usable in an RTP
session, since there may be middleboxes on the path between the
participants which don't pass ECN-marked packets (for example, a
firewall that blocks traffic with the ECN bits set). This document
defines the information that needs to be negotiated, and provides a
mapping to SDP for use in both declarative and offer/answer
contexts.</t>
<t>When a sender joins a session for which all participants claim to
support ECN, it must verify if that support is usable. There are three
ways in which this verification can be done: <list style="symbols">
<t>The sender may generate a (small) subset of its RTP data packets
with the ECN field set to ECT(0) or ECT(1). Each receiver will then
send an RTCP feedback packet indicating the reception of the ECT
marked RTP packets. Upon reception of this feedback from each
receiver it knows of, the sender can consider ECN functional for its
traffic. Each sender does this verification independently. When a
new receiver joins an existing RTP session, it will send RTCP
reports in the usual manner. If those RTCP reports include ECN
information, verification will have succeeded and sources can
continue to send ECT packets. If not, verification fails and each
sender MUST stop using ECN (see <xref
target="sec-rtp-init-ecn"></xref> for details).</t>
<t>Alternatively, ECN support can be verified during an initial
end-to-end STUN exchange (for example, as part of ICE connection
establishment). After having verified connectivity without ECN
capability an extra STUN exchange, this time with the ECN field set
to ECT(0) or ECT(1), is performed on the candidate path that is
about to be used. 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 STUN request was received (see
<xref target="sec-stun-init-ecn"></xref>), along with an ICE
signalling option (<xref target="sec-ice-ecn"></xref>) to indicate
that the check is to be performed.</t>
<t>Thirdly, the sender may make a leap of faith that ECN will work.
This is only recommended for applications that know they are running
in controlled environments where ECN functionality has been verified
through other means. In this mode it is assumed that ECN works, and
the system reacts to failure indicators if the assumption proved
wrong. The use of this method relies on a high confidence that ECN
operation will be successful, or an application where failure is not
serious. The impact on the network and other users must be
considered when making a leap of faith, so there are limitations on
when this method is allowed (see <xref
target="sec-leap-init-ecn"></xref>).</t>
</list>The first mechanism, using RTP with RTCP feedback, has the
advantage of working for all RTP sessions, but the disadvantages of
potential clipping if ECN marked RTP packets are discarded by
middleboxes, and slow verification of ECN support. The STUN-based
mechanism is faster to verify ECN support, but only works in those
scenarios supported by end-to-end STUN, such as within an ICE exchange.
The third one, 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 re-marks ECT marked
packets to non-ECT, possibly marking packets with an ECN-CE mark as
non-ECT. This could result in increased levels of congestion due to
non-responsiveness, and impact media quality as applications end up
relying on packet loss as an indication of congestion.</t>
<t>Once ECN support has been verified (or assumed) to work for all
receivers, a sender marks all its RTP packets as ECT packets, while
receivers rapidly feed back reports on any ECN-CE marks to the sender
using RTCP in RTP/AVPF immediate or early feedback mode, unless no
timely feedback is required. Each feedback report indicates the receipt
of new ECN-CE marks since the last ECN feedback packet, and also counts
the total number of ECN-CE marked packets as a cumulative sum. This is
the mechanism to provide the fastest possible feedback to senders about
ECN-CE marks. On receipt of an ECN-CE marked packet, the system must
react to congestion as-if packet loss has been reported. <xref
target="sec-ongoing"></xref> describes the ongoing use of ECN within an
RTP session.</t>
<t>This rapid feedback is not optimised for reliability, so another
mechanism, RTCP XR ECN summary reports, is used to ensure more reliable,
but less timely, reporting of the ECN information. The ECN summary
report contains the same information as the ECN feedback format, only
packed differently for better efficiency with reports for many sources.
It is sent in a compound RTCP packet, along with regular RTCP reception
reports. By using cumulative counters for observed ECN-CE, ECT, not-ECT,
packet duplication, and packet loss the sender can determine what events
have happened since the last report, independently of any RTCP packets
having been lost.</t>
<t>RTCP reports MUST NOT be ECT marked, since ECT marked traffic may be
dropped if the path is not ECN compliant. RTCP is used to provide
feedback about what has been transmitted and what ECN markings that are
received, so it is important that it is received in cases when ECT
marked traffic is not getting through.</t>
<t>There are numerous reasons why the path the RTP packets take from the
sender to the receiver may change, e.g., mobility, link failure followed
by re-routing around it. Such an event may result in the packet being
sent through a node that is ECN non-compliant, thus re-marking or
dropping packets with ECT set. To prevent this from impacting the
application for longer than necessary, the operation of ECN is
constantly monitored by all senders (<xref
target="sec-ecn-failure"></xref>). Both the RTCP XR ECN summary reports
and the ECN feedback packets allow the sender to compare the number of
ECT(0), ECT(1), and non-ECT marked packets received with the number that
were sent, while also reporting ECN-CE marked and lost packets. If these
numbers do not agree, it can be inferred that the path does not reliably
pass ECN-marked packets. A sender detecting a possible ECN
non-compliance issue should then stop sending ECT marked packets to
determine if that allows the packets to be correctly delivered. If the
issues can be connected to ECN, then ECN usage is suspended.</t>
</section>
<section anchor="sec-rtcp-ecn" title="RTCP Extensions for ECN feedback">
<t>This memo defines two new RTCP extensions: one RTP/AVPF <xref
target="RFC4585"></xref> transport layer feedback format for urgent ECN
information, and one RTCP XR <xref target="RFC3611"></xref> ECN summary
report block type for regular reporting of the ECN marking
information.</t>
<section anchor="sec-rtcp-ecn-fb"
title="RTP/AVPF Transport Layer ECN Feedback packet">
<t>This RTP/AVPF transport layer feedback format is intended for use
in RTP/AVPF early or immediate feedback modes when information needs
to urgently reach the sender. Thus its main use is to report reception
of an ECN-CE marked RTP packet so that the sender may perform
congestion control, or to speed up the initiation procedures by
rapidly reporting that the path can support ECN-marked traffic. The
feedback format is also defined with <xref target="RFC5506">reduced
size RTCP</xref> in mind, where RTCP feedback packets may be sent
without accompanying Sender or Receiver Reports that would contain the
Extended Highest Sequence number and the accumulated number of packet
losses. Both are important for ECN to verify functionality and keep
track of when CE marking does occur.</t>
<t>The RTP/AVPF transport layer feedback packet starts with the common
header defined by the <xref target="RFC4585">RTP/AVPF profile</xref>
which is reproduced in <xref target="fig-avpf-common"></xref>. The FMT
field takes the value [TBA1] to indicate that the Feedback Control
Information (FCI) contains ECN Feedback report, as defined in <xref
target="fig-ecn-feedback"></xref>.</t>
<figure anchor="fig-avpf-common"
title="RTP/AVPF Common Packet Format for Feedback Messages">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT=TBA1| PT=RTPFB=205 | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
]]></artwork>
</figure>
<figure anchor="fig-ecn-feedback" title="ECN Feedback Report Format">
<artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Highest Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Packet Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The ECN Feedback Report contains the following fields:</t>
<t><list style="hanging">
<t hangText="Extended Highest Sequence Number:">The 32-bit
Extended highest sequence number received, as defined by <xref
target="RFC3550"></xref>. Indicates the highest RTP sequence
number to which this report relates.</t>
<t hangText="ECT(0) Counter:">The 32-bit cumulative number of RTP
packets with ECT(0) received from this SSRC.</t>
<t hangText="ECT(1) Counter:">The 32-bit cumulative number of RTP
packets with ECT(1) received from this SSRC.</t>
<t hangText="ECN-CE Counter:">The cumulative number of RTP packets
received from this SSRC since the receiver joined the RTP session
that were ECN-CE marked, including ECN-CE marks in any duplicate
packets. The receiver should keep track of this value using a
local representation that is at least 32-bits, and only include
the 16-bits with least significance. In other words, the field
will wrap if more than 65535 ECN-CE marked packets have been
received.</t>
<t hangText="not-ECT Counter:">The cumulative number of RTP
packets received from this SSRC since the receiver joined the RTP
session that had an ECN field value of not-ECT. The receiver
should keep track of this value using a local representation that
is at least 32-bits, and only include the 16-bits with least
significance. In other words, the field will wrap if more than
65535 not-ECT packets have been received.</t>
<t hangText="Lost Packets Counter:">The cumulative number of RTP
packets that the receiver expected to receive minus the number of
packets it actually received that are not a duplicate of an
already received packet, from this SSRC since the receiver joined
the RTP session. Note that packets that arrive late are not
counted as lost. The receiver should keep track of this value
using a local representation that is at least 32-bits, and only
include the 16-bits with least significance. In other words, the
field will wrap if more than 65535 packets are lost.</t>
<t hangText="Duplication Counter:">The cumulative number of RTP
packets received that are a duplicate of an already received
packet from this SSRC since the receiver joined the RTP session.
The receiver should keep track of this value using a local
representation that is at least 32-bits, and only include the
16-bits with least significance. In other words, the field will
wrap if more than 65535 duplicate packets have been received.</t>
</list>All fields in the ECN Feedback Report are unsigned integers
in network byte order. Each ECN Feedback Report corresponds to a
single RTP source (SSRC). Multiple sources can be reported by
including multiple ECN Feedback Reports packets in an compound RTCP
packet.</t>
<t>The counters SHALL be initiated to 0 for each new SSRC received.
This to enable detection of ECN-CE marks or Packet loss on the initial
report from a specific participant.</t>
<t>The use of at least 32-bit counters allows even extremely high
packet volume applications to not have wrapping of counters within any
timescale close to the RTCP reporting intervals. However, 32-bits are
not sufficiently large to disregard the fact that wrappings may happen
during the life time of a long-lived RTP session. Thus handling of
wrapping of these counters MUST be supported. It is recommended that
implementations uses local representation of these counters that are
longer than 32-bits to enable easy handling of wraps.</t>
<t>There is a difference in packet duplication reports between the
packet loss counter that is defined in the <xref target="RFC3550">
Receiver Report Block</xref> and that defined here. To avoid holding
state for what RTP sequence numbers have been received, <xref
target="RFC3550"></xref> specifies that one can count packet loss by
counting the number of received packets and comparing it to the number
of packets expected. As a result a packet duplication can hide a
packet loss. However, when populating the ECN Feedback report, a
receiver needs to track the sequence numbers actually received and
count duplicates and packet loss separately to provide a more reliable
indication. Reordering may however still result in that packet loss is
reported in one report and then removed in the next.</t>
<t>The ECN-CE counter is robust for packet duplication. Adding each
received ECN-CE marked packet to the counter is not an issue, in fact
it is required to ensure complete tracking of the ECN state. If one of
the clones was ECN-CE marked that is still an indication of
congestion. Packet duplication has potential impact on the ECN
verification and thus there is a need to count the duplicates.</t>
</section>
<section anchor="sec-ecn-summary-report"
title="RTCP XR Report block for ECN summary information">
<t>This unilateral XR report block combined with RTCP SR or RR report
blocks carries the same information as the ECN Feedback Report and is
be based on the same underlying information. However, the ECN Feedback
Report is intended to report on an ECN-CE mark as soon as possible,
while this extended report is for the regular RTCP reporting and
continuous verification of the ECN functionality end-to-end.</t>
<t>The ECN Summary report block consists of one RTCP XR report block
header, shown in <xref target="fig-xr-header"></xref> followed by one
or more ECN summary report data blocks, as defined in <xref
target="fig-xr-ecn-summary"></xref>.</t>
<figure anchor="fig-xr-header" title="RTCP XR Report Header">
<artwork><![CDATA[
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=[TBA2] | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure>
<t><figure anchor="fig-xr-ecn-summary"
title="RTCP XR ECN Summary Report">
<artwork><![CDATA[
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECN-CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Loss Packet Counter | Duplication Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t>The RTCP XR ECN Summary Report contains the following fields:</t>
<t><list style="hanging">
<t hangText="BT:">Block Type identifying the ECN summary report
block. Value is [TBA2].</t>
<t hangText="Reserved:">All bits SHALL be set to 0 on transmission
and ignored on reception.</t>
<t hangText="Block Length:">The length of the report block. Used
to indicate the number of report data blocks present in the ECN
summary report. This length will be 5*n, where n is the number of
ECN summary report blocks, since blocks are a fixed size. The
block length MAY be zero if there is nothing to report. Receivers
MUST discard reports where the block length is not a multiple of
five octets, since these cannot be valid.</t>
<t hangText="SSRC of Media Sender:">The SSRC identifying the media
sender this report is for.</t>
<t hangText="ECT(0) Counter:">as in <xref
target="sec-rtcp-ecn-fb"></xref>.</t>
<t hangText="ECT(1) Counter:">as in <xref
target="sec-rtcp-ecn-fb"></xref>.</t>
<t hangText="ECN-CE Counter:">as in <xref
target="sec-rtcp-ecn-fb"></xref>.</t>
<t hangText="not-ECT Counter:">as in <xref
target="sec-rtcp-ecn-fb"></xref>.</t>
<t hangText="Loss Packet Counter:">as in <xref
target="sec-rtcp-ecn-fb"></xref>.</t>
<t hangText="Duplication Counter:">as in <xref
target="sec-rtcp-ecn-fb"></xref>.</t>
</list></t>
<t>The Extended Highest Sequence number 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 rely on the information sent
in the Sender Report (SR) or Receiver Report (RR) blocks part of the
same RTCP compound packet. The Extended Highest Sequence number is
available from the SR or RR.</t>
<t>All the SSRCs that are present in the SR or RR SHOULD also be
included in the RTCP XR ECN summary report. In cases where the number
of senders are so large that the combination of SR/RR and the ECN
summary for all the senders exceed the MTU, then only a subset of the
senders SHOULD be included so that the reports for the subset fits
within the MTU. The subsets SHOULD be selected round-robin across
multiple intervals so that all sources are periodically reported. In
case there are no SSRCs that currently are counted as senders in the
session, the report block SHALL still be sent with no report block
entry and a zero report block length to continuously indicate to the
other participants the receiver capability to report ECN
information.</t>
</section>
</section>
<section anchor="sec-sdp-ext" title="SDP Signalling Extensions for ECN">
<t>This section defines a number of SDP signalling extensions used in
the negotiation of the ECN for RTP support when using SDP. This includes
one SDP attribute "ecn-capable-rtp" that negotiates the actual operation
of ECN for RTP. Two SDP signalling parameters are defined to indicate
the use of the RTCP XR ECN summary block and the RTP/AVPF feedback
format for ECN. One ICE option SDP representation is also defined.</t>
<section anchor="sec-sdp-ecn"
title="Signalling ECN Capability using SDP">
<t>One new SDP attribute, "a=ecn-capable-rtp", is defined. This is a
media level attribute, and MUST NOT be used at the session level. It
is not subject to the character set chosen. The aim of this signalling
is to indicate the capability of the sender and receivers to support
ECN, and to negotiate the method of ECN initiation to be used in the
session. The attribute takes a list of initiation methods, ordered in
decreasing preference. The defined values for the initiation method
are:</t>
<t><list style="hanging">
<t hangText="rtp:">Using RTP and RTCP as defined in <xref
target="sec-rtp-init-ecn"></xref>.</t>
<t hangText="ice:">Using STUN within ICE as defined in <xref
target="sec-stun-init-ecn"></xref>.</t>
<t hangText="leap:">Using the leap of faith method as defined in
<xref target="sec-leap-init-ecn"></xref>.</t>
</list></t>
<t>Further methods may be specified in the future, so unknown methods
MUST be ignored upon reception.</t>
<t>In addition, a number of OPTIONAL parameters may be included in the
"a=ecn-capable-rtp" attribute as follows:</t>
<t><list style="hanging">
<t hangText="mode:">This 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 congestion
has occurred for incoming packets, 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 both set it to
"readonly".</t>
<t hangText="ect:">This parameter makes it possible to express the
preferred ECT marking. This is either "random", "0", or "1", with
"0" being implied if not specified. 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. It is RECOMMENDED
that ECT(0) marking be used.</t>
</list></t>
<t>The <xref target="RFC5234">ABNF</xref> grammar for the
"a=ecn-capable-rtp" attribute is shown in <xref
target="fig.abnf"></xref>.</t>
<t><figure anchor="fig.abnf"
title="ABNF Grammar for the "a=ecn-capable-rtp" attribute">
<artwork><![CDATA[ ecn-attribute = "a=ecn-capable-rtp:" SP init-list [SP parm-list]
init-list = init-value *("," init-value)
init-value = "rtp" / "ice" / "leap" / init-ext
init-ext = token
parm-list = parm-value *(";" SP parm-value)
parm-value = mode / ect / parm-ext
mode = "mode=" ("setonly" / "setread" / "readonly")
ect = "ect=" ("0" / "1" / "random")
parm-ext = parm-name "=" parm-value-ext
parm-name = token
parm-value-ext = token / quoted-string
quoted-string = DQUOTE *qdtext DQUOTE
qdtext = %x20-21 / %x23-7E / %x80-FF
; any 8-bit ASCII except <">
; external references:
; token: from RFC 4566
; SP and DQUOTE from RFC 5234]]></artwork>
</figure></t>
<section title="Use of "a=ecn-capable-rtp:" with the Offer/Answer Model">
<t>When SDP is used with the offer/answer model <xref
target="RFC3264"></xref>, the party generating the SDP offer MUST
insert an "a=ecn-capable-rtp" attribute into the media section of
the SDP offer of each RTP session for which it wishes to use ECN.
The attribute includes one or more ECN initiation methods in a comma
separated list in decreasing order of preference, with any number of
optional parameters following. The answering party compares the list
of initiation methods in the offer with those 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, and any optional parameters, 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 in the answer then ECN
MUST NOT be used in any direction for that media flow. If there are
initialization methods that are unknown, they MUST be ignored on
reception and MUST NOT be included in an answer.</t>
<t>The endpoints' capability to set and read ECN marks, as expressed
by the optional "mode=" parameter, determines whether ECN support
can be negotiated for flows in one or both directions:</t>
<t><list style="symbols">
<t>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.</t>
<t>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.</t>
<t>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 or the answer.</t>
<t>An offer that does not include a "mode=" parameter MUST be
treated as-if a "mode=setread" parameter had been included.</t>
</list></t>
<t>In an RTP session using multicast and ECN, participants that
intend to send RTP packets SHOULD support setting ECT marks in RTP
packets (i.e., should be "mode=setonly" or "mode=setread").
Participants receiving data need the capability to read ECN marks on
incoming packets. It is important that receivers can read ECN marks
(are "mode=readonly" or "mode=setread"), since otherwise no sender
in the multicast session will be able to enable ECN. Accordingly,
receivers that are "mode=setonly" SHOULD NOT join multicast RTP
sessions that use ECN. If session participants that are not aware of
the ECN for RTP signalling are invited to a multicast session, and
simply ignore the signalling attribute, the other party in the
offer/answer exchange SHOULD terminate the SDP dialogue so that the
participant leaves the session.</t>
<t>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 sending behaviour of the answering
party, and its value in the answer indicates a sending preference
for the behaviour of the offering party. It will be the senders
choice to honour the receivers preference for what to receive or
not. In multicast sessions, all senders SHOULD set the ECT marks
using the value declared in the "ect=" parameter.</t>
<t>Unknown optional parameters MUST be ignored on reception, and
MUST NOT be included in the answer. That way new parameters may be
introduced and verified to be supported by the other end-point by
having them include it in any answer.</t>
</section>
<section title="Use of "a=ecn-capable-rtp:" with Declarative SDP">
<t>When SDP is used in a declarative manner, for example in a
multicast session using the Session Announcement Protocol (SAP,
<xref target="RFC2974"></xref>), negotiation of session description
parameters is 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 RTP session. The attribute MUST include a single
method of initiation. Participants MUST NOT join such a session
unless they have the capability to receive ECN-marked UDP packets,
implement the method of initiation, and can generate RTCP ECN
feedback. The mode parameter MAY also be included in declarative
usage, to indicate the minimal 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.
However, using "mode=readonly" also in ASM sessions is reasonable,
unless all senders are required to attempt to use ECN for their
outgoing RTP data traffic, in which case the mode needs to be set to
"setread".</t>
</section>
<section title="General Use of the "a=ecn-capable-rtp:" Attribute">
<t>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 TCP, SCTP, or DCCP transport, or for non-RTP
sessions.</t>
<t>As described in <xref target="sec-congestion"></xref>, RTP
sessions using ECN require rapid RTCP ECN feedback, unless timely
feedback is not required due to a receiver driven congestion
control. To ensure that the sender can react to ECN-CE marked
packets timely feedback is usually required. Thus, the use of the
Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) <xref
target="RFC4585"></xref> or other profile that inherits RTP/AVPF's
signalling rules, MUST be signalled unless timely feedback is not
required. If timely feedback is not required it is still RECOMMENDED
to used RTP/AVPF. The signalling of an RTP/AVPF based profile is
likely to be required even if the preferred method of initialization
and the congestion control does not require timely feedback, as the
common interoperable method is likely to be signalled or the
improved fault reaction is desired.</t>
</section>
</section>
<section anchor="sec-fb-sdp-par" title="RTCP ECN Feedback SDP Parameter">
<t>A new "nack" feedback parameter "ecn" is defined to indicate the
usage of the RTCP ECN feedback packet <xref target="sec-rtcp-ecn-fb">
format</xref>. The ABNF <xref target="RFC5234"></xref> definition of
the SDP parameter extension is:</t>
<t><figure>
<artwork><![CDATA[rtcp-fb-nack-param = <See section 4.2 of RFC 4585>
rtcp-fb-nack-param /= ecn-fb-par
ecn-fb-par = SP "ecn"
]]></artwork>
</figure>The offer/answer rules for this SDP feedback parameters are
specified in the <xref target="RFC4585">RTP/AVPF profile</xref>.</t>
</section>
<section anchor="sec-xr-sdp-par" title="XR Block ECN SDP Parameter">
<t>A new unilateral RTCP XR block for ECN summary information is
specified, thus the XR block SDP signalling also needs to be extended
with a parameter. This is done in the same way as for the other XR
blocks. The XR block SDP attribute as defined in Section 5.1 of the
<xref target="RFC3611">RTCP XR specification</xref> is defined to be
extensible. As no parameter values are needed for this ECN summary
block, this parameter extension consists of a simple parameter name
used to indicate support and intent to use the XR block.</t>
<t><figure>
<artwork><![CDATA[xr-format = <See Section 5.1 of [RFC3611]>
xr-format /= ecn-summary-par
ecn-summary-par = "ecn-sum"
]]></artwork>
</figure></t>
<t>For SDP declarative and offer/answer usage, see the <xref
target="RFC3611">RTCP XR specification</xref> and its description of
how to handle unilateral parameters.</t>
</section>
<section anchor="sec-ice-ecn"
title="ICE Parameter to Signal ECN Capability">
<t>One new ICE <xref target="RFC5245"></xref> option, "rtp+ecn", is
defined. 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 the capability to support ECN for RTP-over-UDP flows (via
"a=ice-options: rtp+ecn"). The answering party includes this same
attribute at the session level in the SDP answer if it also has the
capability, and removes the attribute if it does not wish to use ECN,
or doesn't have the capability to use ECN. If the ICE initiation
method (<xref target="sec-stun-init-ecn"></xref>) is actually going to
be used, it is also needs to be explicitly negotiated using the
"a=ecn-capable-rtp" attribute. This ICE option SHALL be included when
the ICE initiation method is offered or declared in the SDP.</t>
<t><list style="empty">
<t>Note: This signalling mechanism is not strictly needed as long
as the STUN ECN testing capability is used within the context of
this document. It may however be useful if the ECN verification
capability is used in additional contexts.</t>
</list></t>
</section>
</section>
<section anchor="sec-definition" title="Use of ECN with RTP/UDP/IP">
<t>In the detailed specification of the behaviour below, the different
functions in the general case will first be discussed. In case special
considerations are needed for middleboxes, multicast usage etc, those
will be specially discussed in related subsections.</t>
<section anchor="sec-signalling" title="Negotiation of ECN Capability">
<t>The first stage of ECN negotiation for RTP-over-UDP is to signal
the capability to use ECN. An RTP system that supports ECN and uses
SDP for its signalling MUST implement the SDP extension to signal ECN
capability as described in <xref target="sec-sdp-ecn"></xref>, the
RTCP ECN feedback SDP parameter defined in <xref
target="sec-fb-sdp-par"></xref>, and the XR Block ECN SDP parameter
defined in <xref target="sec-xr-sdp-par"></xref>. It MAY also
implement alternative ECN capability negotiation schemes, such as the
ICE extension described in <xref target="sec-ice-ecn"></xref>. Other
signalling systems will need to define signalling parameters
corresponding to those defined for SDP.</t>
<t>The "ecn-capable-rtp" SDP attribute MUST be used when employing ECN
for RTP according to this specification in systems using SDP. As the
RTCP XR ECN summary report is required independently of the
initialization method or congestion control scheme, the "rtcp-xr"
attribute with the "ecn-sum" parameter MUST also be used. The
"rtcp-fb" attribute with the "nack" parameter "ecn" MUST be used
whenever the initialization method or a congestion control algorithm
requiring timely sender side knowledge of received CE markings. If the
congestion control scheme requires additional signalling, this should
be indicated as appropriate.</t>
</section>
<section anchor="sec-initiation"
title="Initiation of ECN Use in an RTP Session">
<t>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. All session participants connected over the same transport
will need to use the same initiation method. RTP mixers or translators
can use different initiation methods to different participants that
are connected over different underlying transports. The mixer or
translator will need to do individual signalling with each participant
to ensure it is consistent with the ECN support in those cases where
it does not function as one end-point for the ECN control loop.</t>
<t>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 of ECT or ECN-CE will reach their destination(s). There is some
risk that the use of ECN will result in either reset of the ECN field,
or loss of all packets with ECT or ECN-CE markings. If the path
between the sender and the receivers exhibits either of these
behaviours one needs to stop using ECN immediately to protect both the
network and the application.</t>
<t>The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic
at any time. This is to ensure that packet loss due to ECN marking
will not effect the RTCP traffic and the necessary feedback
information it carries.</t>
<t>An RTP system that supports ECN MUST implement the initiation of
ECN using in-band RTP and RTCP described in <xref
target="sec-rtp-init-ecn"></xref>. It MAY also implement other
mechanisms to initiate ECN support, for example the STUN-based
mechanism described in <xref target="sec-stun-init-ecn"></xref>, or
use the leap of faith option if the session supports the limitations
provided in <xref target="sec-leap-init-ecn"></xref>. If support for
both in-band and out-of-band mechanisms is signalled, the sender
SHOULD try ECN negotiation using STUN with ICE first, and if it fails,
fallback to negotiation using RTP and RTCP ECN feedback.</t>
<t>No matter how ECN usage is initiated, the sender MUST continually
monitor the ability of the network, and all its receivers, to support
ECN, following the mechanisms described in <xref
target="sec-ecn-failure"></xref>. This is necessary because path
changes or changes in the receiver population may invalidate the
ability of the system to use ECN.</t>
<section anchor="sec-rtp-init-ecn"
title="Detection of ECT using RTP and RTCP">
<t>The ECN initiation phase using RTP and RTCP to detect if the
network path supports ECN comprises three stages. Firstly, the RTP
sender generates some small fraction of its traffic with ECT marks
to act as probe for ECN support. Then, on receipt of these
ECT-marked packets, the receivers send RTCP ECN feedback packets and
RTCP ECN summary reports to inform the sender that their path
supports ECN. Finally, the RTP sender makes the decision to use ECN
or not, based on whether the paths to all RTP receivers have been
verified to support ECN.</t>
<t><list style="hanging">
<t hangText="Generating ECN Probe Packets:">During the ECN
initiation phase, an RTP sender SHALL mark a small fraction of
its RTP traffic as ECT, while leaving the reminder of the
packets unmarked. The main reason for only marking some packets
is to maintain usable media delivery during the ECN initiation
phase in those cases where ECN is not supported by the network
path. A secondary reason to send some not-ECT packets are to
ensure that the receivers will send RTCP reports on this sender,
even if all ECT marked packets are lost in transit. The not-ECT
packets also provide a base-line to compare performance
parameters against. A fourth reason for only probing with a
small number of packets is to reduce the risk that significant
numbers of congestion markings might be lost if ECT is cleared
to Not-ECT by an ECN-Reverting Middlebox. Then any resulting
lack of congestion response is likely to have little damaging
affect on others. An RTP sender is RECOMMENDED to send a minimum
of two packets with ECT markings per RTCP reporting interval. In
case a random ECT pattern is intended to be used, at least one
packet with ECT(0) and one with ECT(1) should be sent per
reporting interval; in case a single ECT marking is to be used,
only that ECT value SHOULD be sent. The RTP sender SHALL
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.</t>
<t>This memo does not mandate which RTP packets are marked with
ECT during the ECN initiation phase. An implementation should
insert 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 mark is clearly very media dependent, but the use of
RTP <xref target="I-D.ietf-avt-rtp-no-op">NO-OP payloads</xref>,
if supported, would be an appropriate choice. For audio formats,
if would make sense for the sender to mark comfort noise packets
or similar. For video formats, packets containing P- or
B-frames, rather than I-frames, would be an appropriate choice.
No matter which RTP packets are marked, those packets MUST NOT
be sent in duplicate, with and without ECT, since the RTP
sequence number is used to identify packets that are received
with ECN markings.</t>
<t hangText="Generating RTCP ECN Feedback:">If ECN capability
has been negotiated in an RTP session, the receivers in the
session MUST listen for ECT or ECN-CE marked RTP packets, and
generate RTCP ECN feedback packets (<xref
target="sec-rtcp-ecn-fb"></xref>) to mark their receipt. An
immediate or early (depending on the RTP/AVPF mode) ECN feedback
packet SHOULD be generated on receipt of the first ECT or ECN-CE
marked packet from a sender that has not previously sent any ECT
traffic. Each regular RTCP report MUST also contain an ECN
summary report (<xref target="sec-ecn-summary-report"></xref>).
Reception of subsequent ECN-CE marked packets MUST result in
additional early or immediate ECN feedback packets being sent
unless no timely feedback is required.</t>
<t hangText="Determination of ECN Support:">RTP is a group
communication protocol, where members can join and leave the
group at any time. This complicates the ECN initiation phase,
since the sender must wait until it believes the group
membership has stabilised before it can determine if the paths
to all receivers support ECN (group membership changes after the
ECN initiation phase has completed are discussed in <xref
target="sec-ongoing"></xref>).</t>
<t>An RTP sender shall consider the group membership to be
stable after it has been in the session and sending ECT-marked
probe packets for at least three RTCP reporting intervals (i.e.,
after sending its third regularly scheduled RTCP packet), and
when a complete RTCP reporting interval has passed without
changes to the group membership. ECN initiation is considered
successful when the group membership is stable, and all known
participants have sent one or more RTCP ECN feedback packets or
RTCP XR ECN summary reports indicating correct receipt of the
ECT-marked RTP packets generated by the sender.</t>
<t>As an optimisation, if an RTP sender is initiating ECN usage
towards a unicast address, then it MAY treat the ECN initiation
as provisionally successful if it receives an RTCP ECN feedback
report or an RTCP XR ECN summary report indicating successful
receipt of the ECT-marked packets, with no negative indications,
from a single RTP receiver (where a single RTP receiver is
considered as all SSRCs used by a single RTCP CNAME). After
declaring provisional success, the sender MAY generate
ECT-marked packets as described in <xref
target="sec-ongoing"></xref>, provided it continues to monitor
the RTCP reports for a period of three RTCP reporting intervals
from the time the ECN initiation started, to check if there are
any other participants in the session. Thus as long as any
additional SSRC that report on the ECN usage are using the same
RTCP CNAME as the previous reports and they are all indicating
functional ECN the sender may continue. If other participants
are detected, i.e., other RTCP CNAMEs, the sender MUST fallback
to only ECT-marking a small fraction of its RTP packets, while
it determines if ECN can be supported following the full
procedure described above. Different RTCP CNAMEs received over
an unicast transport may occur when using translators in a
multi-party RTP session (e.g., when using a centralised
conference bridge). <list style="empty">
<t>Note: The above optimization supports peer to peer
unicast transport with several SSRCs multiplexed onto the
same flow (e.g., a single participant with two video
cameras, or <xref target="RFC4588">SSRC multiplexed RTP
retransmission</xref>). It is desirable to be able to
rapidly negotiate ECN support for such a session, but the
optimisation above can fail if there are implementations
that use the same CNAME for different parts of a distributed
implementation that have different transport characteristics
(e.g., if a single logical endpoint is split across multiple
hosts).</t>
</list></t>
<t>ECN initiation is considered to have failed at the instant
when any RTP session participant sends an RTCP packet that
doesn't contain an RTCP ECN feedback report or ECN summary
report, but has an RTCP RR with an extended RTP sequence number
field that indicates that it should have received multiple
(>3) ECT marked RTP packets. This can be due to failure to
support the ECN feedback format by the receiver or some
middlebox, or the loss of all ECT marked packets. Both indicate
a lack of ECN support.</t>
</list></t>
<t>If the ECN negotiation succeeds, this indicates that the path can
pass some ECN-marked traffic, and that the receivers support ECN
feedback. This does not necessarily imply that the path can robustly
convey ECN feedback; <xref target="sec-ongoing"></xref> describes
the ongoing monitoring that must be performed to ensure the path
continues to robustly support ECN.</t>
<t>When a sender or receiver detects ECN failures on paths they
should log these to enable follow up and statistics gathering
regarding broken paths. The logging mechanism used is implementation
dependent.</t>
</section>
<section anchor="sec-stun-init-ecn"
title="Detection of ECT using STUN with ICE">
<t>This section describes an OPTIONAL method that can be used to
avoid media impact and also ensure an ECN capable path prior to
media transmission. This method is considered in the context where
the session participants are using <xref target="RFC5245">ICE</xref>
to find working connectivity. We need to use ICE rather than STUN
only, as the verification needs to happen from the media sender to
the address and port on which the receiver is listening.</t>
<t>Note that this method is only applicable to sessions when the
remote destinations are unicast addresses. In addition, transport
translators that do not terminate the ECN control loop and may
distribute received packets to more than one other receiver must
either disallow this method (and use the RTP/RTCP method instead),
or implement additional handling as discussed below. This is because
the ICE initialization method verifies the underlying transport to
one particular address and port. If the receiver at that address and
port intends to use the received packets in a multi-point session
then the tested capabilities and the actual session behavior are not
matched.</t>
<t>To minimise the impact of set-up delay, and to prioritise the
fact that one has a working connectivity rather than necessarily
finding the best ECN capable network path, this procedure is applied
after having performed a successful connectivity check for a
candidate, which is nominated for usage. At that point an additional
connectivity check is performed, sending the "ECN Check" attribute
in a STUN packet that is ECT marked. On reception of the packet, a
STUN server supporting this extension will note the received ECN
field value, and send a STUN/UDP/IP packet in reply with the ECN
field set to not-ECT and including an ECN check attribute. A STUN
server that doesn't understand the extension, or is incapable of
reading the ECN values on incoming STUN packets, should follow the
rule in the STUN specification for unknown comprehension-optional
attributes, and ignore the attribute, resulting in the sender
receiving a STUN response without the ECN Check STUN attribute.</t>
<t>The STUN ECN check attribute contains one field and a flag, as
shown in <xref target="fig-ECN-Check"></xref>. The flag indicates
whether the echo field contains a valid value or not. The field is
the ECN echo field, and when valid contains the two ECN bits from
the packet it echoes back. The ECN check attribute is a
comprehension optional attribute.</t>
<t><figure anchor="fig-ECN-Check" title="ECN Check STUN Attribute">
<artwork><![CDATA[ 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |ECF|V|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></t>
<t><list style="hanging">
<t hangText="V:">Valid (1 bit) ECN Echo value field is valid
when set to 1, and invalid when set 0.</t>
<t hangText="ECF:">ECN Echo value field (2 bits) contains the
ECN field value of the STUN packet it echoes back when field is
valid. If invalid the content is arbitrary.</t>
<t hangText="Reserved:">Reserved bits (29 bits) SHALL be set to
0 on transmission, and SHALL be ignored on reception.</t>
</list>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 0. A compliant STUN server receiving a request with
the ECN Check attribute SHALL read the ECN field value of the IP/UDP
packet the request was received in. Upon forming the response the
server SHALL include the ECN Check attribute setting the V bit to
valid and include the read value of the ECN field into the ECF
field. If the STUN responder was unable to ascertain, due to
temporary errors, the ECN value of the STUN request, it SHALL set
the V bit in the response to 0. The STUN client may retry
immediately.</t>
<t>The ICE based initialization method does require some special
consideration when used by a translator. This is especially for
transport translators and translators that fragment or reassemble
packets, since they do not separate the ECN control loops between
the end-points and the translator. When using ICE-based initiation,
such a translator must ensure that any participants joining an RTP
session for which ECN has been negotiated are successfully verified
in the direction from the translator to the joining participant.
Alternatively, it must correctly handle remarking of ECT RTP packets
towards that participant. When a new participant joins the session,
the translator will perform a check towards the new participant. If
that is successfully completed the ECT properties of the session are
maintained for the other senders in the session. If the check fails
then the existing senders will now see a participant that fails to
receive ECT. Thus the failure detection in those senders will
eventually detect this. However to avoid misusing the network on the
path from the translator to the new participant, the translator
SHALL remark the traffic intended to be forwarded from ECT to
non-ECT. Any packet intended to be forward that are ECN-CE marked
SHALL be discard and not sent. In cases where the path from a new
participant to the translator fails the ECT check then only that
sender will not contribute any ECT marked traffic towards the
translator.</t>
</section>
<section anchor="sec-leap-init-ecn"
title="Leap of Faith ECT initiation method">
<t>This method for initiating ECN usage is a leap of faith that
assumes that ECN will work on the used path(s). The method is to go
directly to "ongoing use of ECN" as defined in <xref
target="sec-ongoing"></xref>. 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. 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.</t>
<t>If the sender marks all packets as ECT while transmitting on a
path that contains an ECN-blocking middlebox, then receivers
downstream of that middlebox will not receive any RTP data packets
from the sender, and hence will not consider it to be an active RTP
SSRC. The sender can detect this and revert to sending packets
without ECT marks, since RTCP SR/RR packets from such receivers will
either not include a report for sender's SSRC, or will report that
no packets have been received, but this takes at least one RTCP
reporting interval. It should be noted that a receiver might
generate its first RTCP packet immediately on joining a unicast
session, or very shortly after joining a RTP/AVPF session, before it
has had chance to receive any data packets. A sender that receives
RTCP SR/RR packet indicating lack of reception by a receiver SHOULD
therefore wait for a second RTCP report from that receiver to be
sure that the lack of reception is due to ECT-marking. Since this
recovery process can take several tens of seconds, during which time
the RTP session is unusable for media, it is NOT RECOMMENDED that
the leap-of-faith ECT initiation method be used in environments
where ECN-blocking middleboxes are likely to be present.</t>
</section>
</section>
<section anchor="sec-ongoing"
title="Ongoing Use of ECN Within an RTP Session">
<t>Once ECN has been successfully initiated for an RTP sender, that
sender begins sending all RTP data packets as ECT-marked, and its
receivers send ECN feedback information via RTCP packets. This section
describes procedures for sending ECT-marked data, providing ECN
feedback information via RTCP, responding to ECN feedback information,
and detecting failures and misbehaving receivers.</t>
<section title="Transmission of ECT-marked RTP Packets">
<t>After a sender has successfully initiated ECN use, it SHOULD mark
all the RTP data packets it sends as ECT. The sender SHOULD mark
packets as ECT(0) unless the receiver expresses a preference for
ECT(1) or random using the "ect" parameter in the
"a=ecn-capable-rtp" attribute.</t>
<t>The sender SHALL NOT include ECT marks on outgoing RTCP packets,
and SHOULD NOT include ECT marks on any other outgoing control
messages (e.g., <xref target="RFC5389">STUN</xref> packets, <xref
target="RFC4347">DTLS</xref> handshake packets, or <xref
target="RFC6189">ZRTP</xref> control packets) that are multiplexed
on the same UDP port. For control packets there might be exceptions,
like the STUN based ECN check defined in <xref
target="sec-stun-init-ecn"></xref>.</t>
</section>
<section title="Reporting ECN Feedback via RTCP">
<t>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 feedback packet as soon as possible (subject to the
constraints of <xref target="RFC4585"></xref> and <xref
target="RFC3550"></xref>) to report this back to the sender unless
no timely feedback is required. The feedback RTCP packet SHALL
consist of at least one ECN feedback packet (<xref
target="sec-rtcp-ecn-fb"></xref>) reporting on the packets received
since the last ECN feedback packet, and will contain (at least) an
RTCP SR/RR packet and an SDES packet, unless <xref
target="RFC5506">reduced size RTCP</xref> is used. The RTP/AVPF
profile in early or immediate feedback mode SHOULD be used where
possible, to reduce the interval before feedback can be sent. To
reduce the size of the feedback message, reduced size RTCP <xref
target="RFC5506"></xref> MAY be used if supported by the end-points.
Both RTP/AVPF and reduced size RTCP MUST be negotiated in the
session set-up signalling before they can be used.</t>
<t>Every time a regular compound RTCP packet is to be transmitted,
an ECN-capable RTP receiver MUST include an RTCP XR ECN summary
report as described in <xref target="sec-ecn-summary-report"></xref>
as part of the compound packet.</t>
<t>The multicast feedback implosion problem, that occurs when many
receivers simultaneously send feedback to a single sender, must be
considered. The RTP/AVPF transmission rules will limit the amount of
feedback that can be sent, avoiding the implosion problem but also
delaying feedback by varying degrees from nothing up to a full RTCP
reporting interval. As a result, the full extent of a congestion
situation may take some time to reach the sender, although some
feedback should arrive in a reasonably timely manner, allowing the
sender to react on a single or a few reports.</t>
</section>
<section anchor="sec-congestion"
title="Response to Congestion Notifications">
<t>The reception of RTP packets with ECN-CE marks in the IP header
is a notification that congestion is being experienced. The default
reaction on the reception of these ECN-CE marked packets MUST be to
provide the congestion control algorithm with a congestion
notification that triggers the algorithm to react as if packet loss
had occurred. There should be no difference in congestion response
if ECN-CE marks or packet drops are detected.</t>
<t>We note that there MAY be other reactions to ECN-CE specified in
the future. Such an alternative reaction MUST be specified and
considered to be safe for deployment under any restrictions
specified. A potential example for an alternative reaction could be
emergency communications (such as that generated by first
responders, as opposed to the general public) in networks where the
user has been authorized. A more detailed description of these other
reactions, as well as the types of congestion control algorithms
used by end-nodes, is outside of the scope of this document.</t>
<t>Depending on the media format, type of session, and RTP topology
used, there are several different types of congestion control that
can be used:</t>
<t><list style="hanging">
<t hangText="Sender-Driven Congestion Control:">The sender is
responsible for adapting the transmitted bit-rate in response to
RTCP ECN feedback. When the sender receives the ECN feedback
data it feeds this information into its congestion control or
bit-rate adaptation mechanism so that it can react as if packet
loss was reported. The congestion control algorithm to be used
is not specified here, although TFRC <xref
target="RFC5348"></xref> is one example that might be used.</t>
<t hangText="Receiver-Driven Congestion Control:">If a receiver
driven congestion control mechanism is used, the receiver can
react to the ECN-CE marks without contacting the sender. This
may allow faster response than sender-driven congestion control
in some circumstances. Receiver-driven congestion control is
usually implemented by providing the content in a layered way,
with each layer providing improved media quality but also
increased bandwidth usage. The receiver locally monitors the
ECN-CE marks on received packets to check if it experiences
congestion with the current number of layers. If congestion is
experienced, the receiver drops one layer, so reducing the
resource consumption on the path towards itself. For example, if
a layered media encoding scheme such as H.264 SVC is used, the
receiver may change its layer subscription, and so reduce the
bit rate it receives. The receiver MUST still send RTCP XR ECN
Summary to the sender, even if it can adapt without contact with
the sender, so that the sender can determine if ECN is supported
on the network path. The timeliness of RTCP feedback is less of
a concern with receiver driven congestion control, and regular
RTCP reporting of ECN summary information is sufficient (without
using RTP/AVPF immediate or early feedback).</t>
<t hangText="Hybrid:">There might be mechanisms that utilize
both some receiver behaviors and some sender side monitoring,
thus requiring both feedback of congestion events to the sender
and taking receiver decisions and possible signalling to the
sender. In this case the congestion control algorithm needs to
use the signalling to indicate which features of ECN for RTP are
required.</t>
</list></t>
<t>Responding to congestion indication in the case of multicast
traffic is a more complex problem than for unicast traffic. The
fundamental problem is diverse paths, i.e., when different receivers
don't see the same path, and thus have different bottlenecks, so the
receivers may get ECN-CE marked packets due to congestion at
different points in the network. This is problematic for sender
driven congestion control, since when receivers are heterogeneous in
regards to capacity, the sender is limited to transmitting at the
rate the slowest receiver can support. This often becomes a
significant limitation as group size grows. Also, as group size
increases the frequency of reports from each receiver decreases,
which further reduces the responsiveness of the mechanism.
Receiver-driven congestion control has the advantage that each
receiver can choose the appropriate rate for its network path,
rather than all receivers having to settle for the lowest common
rate.</t>
<t>We note that ECN support is not a silver bullet to improving
performance. The use of ECN gives the chance to respond to
congestion before packets are dropped in the network, improving the
user experience by allowing the RTP application to control how the
quality is reduced. An application which ignores ECN Congestion
Experienced feedback is not immune to congestion: the network will
eventually begin to discard packets if traffic doesn't respond. It
is in the best interest of an application to respond to ECN
congestion feedback promptly, to avoid packet loss.</t>
</section>
</section>
<section anchor="sec-ecn-failure" title="Detecting Failures">
<t>Senders and receivers can deliberately ignore ECN-CE and thus get a
benefit over behaving flows (cheating). Th ECN Nonce <xref
target="RFC3540"></xref> is an addition to TCP that attempts to solve
this issue as long as the sender acts on behalf of the network. The
assumption about the senders acting on the behalf of the network may
be reduced due to the nature of peer-to-peer use of RTP. Still a
significant portion of RTP senders are infrastructure devices (for
example, streaming media servers) that do have an interest in
protecting both service quality and the network. Even though there may
be cases where nonce can be applicable also for RTP, it is not
included in this specification. This as a receiver interested in
cheating would simple claim to not support nonce, or even ECN itself.
It is, however, worth mentioning that, as real-time media is commonly
sensitive to increased delay and packet loss, it will be in both the
media sender and receivers interest to minimise the number and
duration of any congestion events as they will adversely affect media
quality.</t>
<t>RTP sessions can also suffer from path changes resulting in a
non-ECN compliant node becoming part of the path. That node may
perform either of two actions that has effect on the ECN and
application functionality. The gravest is if the node drops packets
with the ECN field set to ECT(0), ECT(1), or ECN-CE. This can be
detected by the receiver when it receives an RTCP SR packet indicating
that a sender has sent a number of packets that it has not received.
The sender may also detect such a middlebox based on the receiver's
RTCP RR packet, when the extended sequence 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 the ECN feedback
information or RTCP RR will indicate the situation. The other action
is to re-mark a packet from ECT or ECN-CE to not-ECT. That has less
dire results, however it should be detected so that ECN usage can be
suspended to prevent misusing the network.</t>
<t>The RTCP XR ECN summary packet and the ECN feedback packet allow
the sender to compare the number of ECT marked packets of different
types received with the number it actually sent. The number of ECT
packets received, plus the number of ECN-CE marked and lost packets,
should correspond to the number of sent ECT marked packets plus the
number of received duplicates. If these numbers doesn't agree there
are two likely reasons, a translator changing the stream or not
carrying the ECN markings forward, or that some node re-marks the
packets. In both cases the usage of ECN is broken on the path. By
tracking all the different possible ECN field values a sender can
quickly detect if some non-compliant behavior is happening on the
path.</t>
<t>Thus packet losses and non-matching ECN field value statistics are
possible indication of issues with using ECN over the path. The next
section defines both sender and receiver reactions to these cases.</t>
<section anchor="sec-fallback" title="Fallback mechanisms">
<t>Upon the detection of a potential failure, both the sender and
the receiver can react to mitigate the situation.</t>
<t>A receiver that detects a packet loss burst MAY schedule an early
feedback packet that includes at least the RTCP RR and the ECN
feedback message to report this to the sender. This will speed up
the detection of the loss at the sender, thus triggering sender side
mitigation.</t>
<t>A sender that detects high packet loss rates for ECT-marked
packets SHOULD immediately switch to sending packets as not-ECT to
determine if the losses are potentially due to the ECT markings. If
the losses disappear when the ECT-marking is discontinued, the RTP
sender should go back to initiation procedures to attempt to verify
the apparent loss of ECN capability of the used path. If a
re-initiation fails then the two possible actions exist:</t>
<t><list style="numbers">
<t>Periodically retry the ECN initiation to detect if a path
change occurs to a path that is ECN capable.</t>
<t>Renegotiate the session to disable ECN support. This is a
choice that is suitable if the impact of ECT probing on the
media quality is noticeable. If multiple initiations have been
successful, but the following full usage of ECN has resulted in
the fallback procedures, then disabling of the ECN support is
RECOMMENDED.</t>
</list>We foresee the possibility of flapping ECN capability due
to several reasons: video switching MCU or similar middleboxes that
selects to deliver media from the sender only intermittently; load
balancing devices may in worst case result in that some packets take
a different network path then the others; mobility solutions that
switch underlying network path in a transparent way for the sender
or receiver; and membership changes in a multicast group. It is
however appropriate to mention that there are also issues such as
re-routing of traffic due to a flappy route table or excessive
reordering and other issues that are not directly ECN related but
nevertheless may cause problems for ECN.</t>
</section>
<section anchor="sec-interpret"
title="Interpretation of ECN Summary information">
<t>This section contains discussion on how the ECN summary report
information can be used to detect various types of ECN path issues.
We first review the information the RTCP reports provide on a per
source (SSRC) basis:</t>
<t><list style="hanging">
<t hangText="ECN-CE Counter:">The number of RTP packets received
so far in the session with an ECN field set to CE.</t>
<t hangText="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.</t>
<t hangText="not-ECT Counter:">The number of RTP packets
received so far in the session with an ECN field set to
not-ECT.</t>
<t hangText="Lost Packets counter:">The number of RTP packets
that where expected based on sequence numbers but never
received.</t>
<t hangText="Duplication Counter:">The number of received RTP
packets that are duplicates of already received ones.</t>
<t hangText="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.</t>
</list>The counters will be initialised to zero to provide value
for the RTP stream sender from the first report. After the first
report, the changes between the last received report and the
previous report are determined by simply taking the values of the
latest minus the previous, taking wrapping into account. This
definition is also robust to packet losses, since if one report is
missing, the reporting interval becomes longer, but is otherwise
equally valid.</t>
<t>In a perfect world, the number of not-ECT packets received should
be equal to the number sent minus the lost packets counter, and the
sum of the ECT(0), ECT(1), and ECN-CE counters should be equal to
the number of ECT marked packet sent. Two issues may cause a
mismatch in these statistics: severe network congestion or
unresponsive congestion control might cause some ECT-marked packets
to be lost, and packet duplication might result in some packets
being received, and counted in the statistics, multiple times
(potentially with a different ECN-mark on each copy of the
duplicate).</t>
<t>The rate of packet duplication is tracked, allowing one to take
the duplication into account. The value of the ECN field for
duplicates will also be counted and when comparing the figures one
needs to take some fraction of packet duplicates that are non-ECT
and some fraction of packet duplicates being ECT into account into
the calculation. Thus when only sending non-ECT then the number of
sent packets plus reported duplicates equals the number of received
non-ECT. When sending only ECT then number of sent ECT packets plus
duplicates will equal ECT(0), ECT(1), ECN-CE and packet loss. When
sending a mix of non-ECT and ECT then there is an uncertainty if any
duplicate or packet loss was an non-ECT or ECT. If the packet
duplication is completely independent of the usage of ECN, then the
fraction of packet duplicates should be in relation to the number of
non-ECT vs ECT packet sent during the period of comparison. This
relation does not hold for packet loss, where higher rates of packet
loss for non-ECT is expected than for ECT traffic.</t>
<t>Detecting clearing of ECN field: If the ratio between ECT and
not-ECT transmitted in the reports has become all not-ECT, or has
substantially changed towards not-ECT, then this is clearly an
indication that the path results in clearing of the ECT field.</t>
<t>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. One must also take into account
the level of CE marking. A CE marked packet would have been dropped
unless it was ECT marked. Thus, the packet loss level for not-ECT
should be approximately equal to the loss rate for ECT when counting
the CE marked packets as lost ones. A sender performing this
calculation needs to ensure that the difference is statistically
significant.</t>
<t>If erroneous behavior is detected, it should be logged to enable
follow up and statistics gathering.</t>
</section>
</section>
</section>
<section anchor="sec-rtcp-translator-mixer"
title="Processing ECN in RTP Translators and Mixers">
<t>RTP translators and mixers that support ECN for RTP are required to
process, and potentially modify or generate ECN marking in RTP packets.
They also need to process, and potentially modify or generate RTCP ECN
feedback packets for the translated and/or mixed streams. This includes
both downstream RTCP reports generated by the media sender, and also
reports generated by the receivers, flowing upstream back towards the
sender.</t>
<section anchor="sec-rtcp-trn-translator" title="Transport Translators">
<t>Some translators only perform transport level translations, like
copying packets from one address domain, like unicast to multicast. It
may also perform relaying like copying an incoming packet to a number
of unicast receivers. This section details the ECN related actions for
RTP and RTCP.</t>
<t>For the RTP data packets the translator, which does not modify the
media stream, SHOULD copy the ECN bits unchanged from the incoming to
the outgoing datagrams, unless the translator itself is overloaded and
experiencing congestion, in which case it may mark the outgoing
datagrams with an ECN-CE mark.</t>
<t>A Transport translator does not modify RTCP packets. It however
MUST perform the corresponding transport translation of the RTCP
packets as it does with RTP packets being sent from the same
source/end-point.</t>
</section>
<section anchor="sec-rtcp-ecn-translator"
title="Fragmentation and Reassembly in Translators">
<t>An RTP translator may fragment or reassemble RTP data packets
without changing the media encoding, and without reference to the
congestion state of the networks it bridges. An example of this might
be to combine packets of a voice-over-IP stream coded with one 20ms
frame per RTP packet into new RTP packets with two 20ms frames per
packet, thereby reducing the header overheads and so stream bandwidth,
at the expense of an increase in latency. If multiple data packets are
re-encoded into one, or vice versa, the RTP translator MUST assign new
sequence numbers to the outgoing packets. Losses in the incoming RTP
packet stream may also induce corresponding gaps in the outgoing RTP
sequence numbers. An RTP translator MUST rewrite RTCP packets to make
the corresponding changes to their sequence numbers, and to reflect
the impact of the fragmentation or reassembly. This section describes
how that rewriting is to be done for RTCP ECN feedback packets.
Section 7.2 of <xref target="RFC3550"></xref> describes general
procedures for other RTCP packet types.</t>
<t>The processing of arriving RTP packets for this case is as follows.
If an ECN marked packet is split into two, then both the outgoing
packets MUST be ECN marked identically to the original; if several ECN
marked packets are combined into one, the outgoing packet MUST be
either ECN-CE marked or dropped if any of the incoming packets are
ECN-CE marked. If the outgoing combined packet is not ECN-CE marked,
then it MUST be ECT marked if any of the incoming packets were ECT
marked.</t>
<t>RTCP ECN feedback packets (<xref target="sec-rtcp-ecn-fb"></xref>)
contain seven fields that are rewritten in an RTP translator that
fragments or reassembles packets: the extended highest sequence
number, the duplication counter, the lost packets counter, the ECN-CE
counter, and not-ECT counter, the ECT(0) counter, and the ECT(1)
counter. The RTCP XR report block for ECN summary information (<xref
target="sec-ecn-summary-report"></xref>) includes all of these fields
except the extended highest sequence number which is present in the
report block in an SR or RR packet. The procedures for rewriting these
fields are the same for both RTCP ECN feedback packet and the RTCP XR
ECN summary packet.</t>
<t>When receiving an RTCP ECN feedback packet for the translated
stream, an RTP translator first determines the range of packets to
which the report corresponds. The extended highest sequence number in
the RTCP ECN feedback packet (or in the RTCP SR/RR packet contained
within the compound packet, in the case of RTCP XR ECN summary
reports) specifies the end sequence number of the range. For the first
RTCP ECN feedback packet received, the initial extended sequence
number of the range may be determined by subtracting the sum of the
lost packets counter, the ECN-CE counter, the not-ECT counter, the
ECT(0) counter and the ECT(1) counter minus the duplication counter,
from the extended highest sequence number. For subsequent RTCP ECN
feedback packets, the starting sequence number may be determined as
being one after the extended highest sequence number of the previous
RTCP ECN feedback packet received from the same SSRC. These values are
in the sequence number space of the translated packets.</t>
<t>Based on its knowledge of the translation process, the translator
determines the sequence number range for the corresponding original,
pre-translation, packets. The extended highest sequence number in the
RTCP ECN feedback packet is rewritten to match the final sequence
number in the pre-translation sequence number range.</t>
<t>The translator then determines the ratio, R, of the number of
packets in the translated sequence number space (numTrans) to the
number of packets in the pre-translation sequence number space
(numOrig) such that R = numTrans / numOrig. The counter values in the
RTCP ECN feedback report are then scaled by dividing each of them by
R. For example, if the translation process combines two RTP packets
into one, then numOrig will be twice numTrans, giving R=0.5, and the
counters in the translated RTCP ECN feedback packet will be twice
those in the original.</t>
<!--MW: Do we need to discuss the need for keeping base sequence number and pick new ones
at the front of already translated range every time the R factor changes? -->
<t>The ratio, R, may have a value that leads to non-integer multiples
of the counters when translating the RTCP packet. For example, a VoIP
translator that combines two adjacent RTP packets into one if they
contain active speech data, but passes comfort noise packets
unchanged, would have an R values of between 0.5 and 1.0 depending on
the amount of active speech. Since the counter values in the
translated RTCP report are integer values, rounding will be necessary
in this case.</t>
<t>When rounding counter values in the translated RTCP packet, the
translator should try to ensure that they sum to the number of RTP
packets in the pre-translation sequence number space (numOrig). The
translator should also try to ensure that no non-zero counter is
rounded to a zero value, since that will lose information that a
particular type of event has occurred. It is recognised that it may be
impossible to satisfy both of these constraints; in such cases, it is
better to ensure that no non-zero counter is mapped to a zero value,
since this preserves congestion adaptation and helps the RTCP-based
ECN initiation process.</t>
<t>One should be aware of the impact this type of translators have on
the measurement of packet duplication. A translator performing
aggregation and most likely also an fragmenting translator will
suppress any duplication happening prior to itself. Thus the reports
and what is being scaled will only represent packet duplication
happening from the translator to the receiver reporting on the
flow.</t>
<t>It should be noted that scaling the RTCP counter values in this way
is meaningful only on the assumption that the level of congestion in
the network is related to the number of packets being sent. This is
likely to be a reasonable assumption in the type of environment where
RTP translators that fragment or reassemble packets are deployed, as
their entire purpose is to change the number of packets being sent to
adapt to known limitations of the network, but is not necessarily
valid in general.</t>
<t>The rewritten RTCP ECN feedback report is sent from the other side
of the translator to that which it arrived (as part of a compound RTCP
packet containing other translated RTCP packets, where
appropriate).</t>
</section>
<section anchor="sec-rtcp-ecn-synthetic"
title="Generating RTCP ECN Feedback in Media Transcoders">
<t>An RTP translator that acts as a media transcoder cannot directly
forward RTCP packets corresponding to the transcoded stream, since
those packets will relate to the non-transcoded stream, and will not
be useful in relation to the transcoded RTP flow. Such a transcoder
will need to interpose itself into the RTCP flow, acting as a proxy
for the receiver to generate RTCP feedback in the direction of the
sender relating to the pre-transcoded stream, and acting in place of
the sender to generate RTCP relating to the transcoded stream, to be
sent towards the receiver. This section describes how this proxying is
to be done for RTCP ECN feedback packets. Section 7.2 of <xref
target="RFC3550"></xref> describes general procedures for other RTCP
packet types.</t>
<t>An RTP translator acting as a media transcoder in this manner does
not have its own SSRC, and hence is not visible to other entities at
the RTP layer. RTCP ECN feedback packets and RTCP XR report blocks for
ECN summary information that are received from downstream relate to
the translated stream, and so must be processed by the translator as
if it were the original media source. These reports drive the
congestion control loop and media adaptation between the translator
and the downstream receiver. If there are multiple downstream
receivers, a logically separate transcoder instance must be used for
each receiver, and must process RTCP ECN feedback and summary reports
independently to the other transcoder instances. An RTP translator
acting as a media transcoder in this manner MUST NOT forward RTCP ECN
feedback packets or RTCP XR ECN summary reports from downstream
receivers in the upstream direction.</t>
<t>An RTP translator acting as a media transcoder will generate RTCP
reports upstream towards the original media sender, based on the
reception quality of the original media stream at the translator. The
translator will run a separate congestion control loop and media
adaptation between itself and the media sender for each of its
downstream receivers, and must generate RTCP ECN feedback packets and
RTCP XR ECN summary reports for that congestion control loop using the
SSRC of that downstream receiver.</t>
</section>
<section anchor="sec-rtcp-mixer"
title="Generating RTCP ECN Feedback in Mixers">
<t>An RTP mixer terminates one-or-more RTP flows, combines them into a
single outgoing media stream, and transmits that new stream as a
separate RTP flow. A mixer has its own SSRC, and is visible to other
participants in the session at the RTP layer.</t>
<t>An ECN-aware RTP mixer must generate RTCP ECN feedback packets and
RTCP XR report blocks for ECN summary information relating to the RTP
flows it terminates, in exactly the same way it would if it were an
RTP receiver. These reports form part of the congestion control loop
between the mixer and the media senders generating the streams it is
mixing. A separate control loop runs between each sender and the
mixer.</t>
<t>An ECN-aware RTP mixer will negotiate and initiate the use of ECN
on the mixed RTP flows it generates, and will accept and process RTCP
ECN feedback reports and RTCP XR report blocks for ECN relating to
those mixed flows as if it were a standard media sender. A congestion
control loop runs between the mixer and its receivers, driven in part
by the ECN reports received.</t>
<t>An RTP mixer MUST NOT forward RTCP ECN feedback packets or RTCP XR
ECN summary reports from downstream receivers in the upstream
direction.</t>
</section>
</section>
<section anchor="sec-impl" title="Implementation considerations">
<t>To allow the use of ECN with RTP over UDP, the RTP implementation
should be able to set the ECT bits in outgoing UDP datagrams, and should
be able to read the value of the ECT bits on received UDP datagrams. The
standard Berkeley sockets API pre-dates the specification of ECN, and
does not provide the functionality which is required for this mechanism
to be used with UDP flows, making this specification difficult to
implement portably.</t>
</section>
<section anchor="sec-iana" title="IANA Considerations">
<t>Note to RFC Editor: please replace "RFC XXXX" below with the RFC
number of this memo, and remove this note.</t>
<section title="SDP Attribute Registration">
<t>Following the guidelines in <xref target="RFC4566"></xref>, the
IANA is requested to register one new SDP attribute:<list
style="symbols">
<t>Contact name, email address and telephone number: Authors of
RFCXXXX</t>
<t>Attribute-name: ecn-capable-rtp</t>
<t>Type of attribute: media-level</t>
<t>Subject to charset: no</t>
</list></t>
<t>This attribute defines the ability to negotiate the use of ECT (ECN
capable transport) for RTP flows running over UDP/IP. This attribute
should be put in the SDP offer if the offering party wishes to receive
an ECT flow. The answering party should include the attribute in the
answer if it wish to receive an ECT flow. If the answerer does not
include the attribute then ECT MUST be disabled in both
directions.</t>
</section>
<section title="RTP/AVPF Transport Layer Feedback Message">
<t>The IANA is requested to register one new RTP/AVPF Transport Layer
Feedback Message in the table of FMT values for RTPFB Payload Types
<xref target="RFC4585"></xref> as defined in <xref
target="sec-rtcp-ecn-fb"></xref>:</t>
<figure>
<artwork><![CDATA[
Name: RTCP-ECN-FB
Long name: RTCP ECN Feedback
Value: TBA1
Reference: RFC XXXX
]]></artwork>
</figure>
</section>
<section title="RTCP Feedback SDP Parameter">
<t>The IANA is requested to register one new SDP "rtcp-fb" attribute
"nack" parameter "ecn" in the SDP ("ack" and "nack" Attribute Values)
registry.</t>
<t><figure>
<artwork><![CDATA[ Value name: ecn
Long name: Explicit Congestion Notification
Usable with: nack
Reference: RFC XXXX]]></artwork>
</figure></t>
</section>
<section title="RTCP XR Report blocks">
<t>The IANA is requested to register one new RTCP XR Block Type as
defined in <xref target="sec-ecn-summary-report"></xref>:</t>
<figure>
<artwork><![CDATA[
Block Type: TBA2
Name: ECN Summary Report
Reference: RFC XXXX
]]></artwork>
</figure>
</section>
<section title="RTCP XR SDP Parameter">
<t>The IANA is requested to register one new RTCP XR SDP Parameter
"ecn-sum" in the "RTCP XR SDP Parameters" registry.</t>
<t><figure>
<artwork><![CDATA[ Parameter name XR block (block type and name)
-------------- ------------------------------------
ecn-sum TBA2 ECN Summary Report Block]]></artwork>
</figure></t>
</section>
<section anchor="stun-attr" title="STUN attribute">
<t>A new STUN <xref target="RFC5389"></xref> attribute in the
Comprehension-optional range under IETF Review (0x0000 - 0x3FFF) is
request to be assigned to the STUN attribute defined in <xref
target="sec-stun-init-ecn"></xref>. The STUN attribute registry can
currently be found at:
http://www.iana.org/assignments/stun-parameters/stun-parameters.xhtml.</t>
</section>
<section anchor="ice-opt" title="ICE Option">
<t>A new ICE option "rtp+ecn" is registered in the registry that <xref
target="I-D.ietf-mmusic-ice-options-registry">"IANA Registry for
Interactive Connectivity Establishment (ICE) Options"</xref>
creates.</t>
</section>
</section>
<section anchor="sec-security" title="Security Considerations">
<t>The use of ECN with RTP over UDP as specified in this document has
the following known security issues that need to be considered.</t>
<t>External threats to the RTP and RTCP traffic:</t>
<t><list style="hanging">
<t hangText="Denial of Service affecting RTCP:">An attacker that can
modify the traffic between the media sender and a receiver can
achieve either of two things: 1) Report a lot of packets as being
Congestion Experience marked, thus forcing the sender into a
congestion response; or 2) Ensure that the sender disable the usage
of ECN by reporting failures to receive ECN by changing the counter
fields. This can also be accomplished by injecting false RTCP
packets to the media sender. Reporting a lot of ECN-CE marked
traffic is likely the more efficient denial of service tool as that
may likely force the application to use lowest possible bit-rates.
The prevention against an external threat is to integrity protect
the RTCP feedback information and authenticate the sender.</t>
<t hangText="Information leakage:">The ECN feedback mechanism
exposes the receivers perceived packet loss, what packets it
considers to be ECN-CE marked and its calculation of the ECN-none.
This is mostly not considered as sensitive information. If it is
considered sensitive the RTCP feedback should be encrypted.</t>
<t hangText="Changing the ECN bits:">An on-path attacker that sees
the RTP packet flow from sender to receiver and who has the
capability to change the packets can rewrite ECT into ECN-CE thus
forcing the sender or receiver to take congestion control response.
This denial of service against the media quality in the RTP session
is impossible for an end-point to protect itself against. Only
network infrastructure nodes can detect this illicit re-marking. It
will be mitigated by turning off ECN, however, if the attacker can
modify its response to drop packets the same vulnerability
exist.</t>
<t
hangText="Denial of Service affecting the session set-up signalling:">If
an attacker can modify the session signalling it can prevent the
usage of ECN by removing the signalling attributes used to indicate
that the initiator is capable and willing to use ECN with RTP/UDP.
This attack can be prevented by authentication and integrity
protection of the signalling. We do note that any attacker that can
modify the signalling has more interesting attacks they can perform
than prevent the usage of ECN, like inserting itself as a middleman
in the media flows enabling wire-tapping also for an off-path
attacker.</t>
</list></t>
<t>The following are threats that exist from misbehaving senders or
receivers:</t>
<t><list style="hanging">
<t hangText="Receivers cheating:">A receiver may attempt to cheat
and fail to report reception of ECN-CE marked packets. The benefit
for a receiver cheating in its reporting would be to get an unfair
bit-rate share across the resource bottleneck. It is far from
certain that a receiver would be able to get a significant larger
share of the resources. That assumes a high enough level of
aggregation that there are flows to acquire shares from. The risk of
cheating is that failure to react to congestion results in packet
loss and increased path delay.</t>
<t hangText="Receivers misbehaving:">A receiver may prevent the
usage of ECN in an RTP session by reporting itself as non ECN
capable, forcing the sender to turn off usage of ECN. In a
point-to-point scenario there is little incentive to do this as it
will only affect the receiver. Thus failing to utilise an
optimisation. For multi-party session there exist some motivation
why a receiver would misbehave as it can prevent also the other
receivers from using ECN. As an insider into the session it is
difficult to determine if a receiver is misbehaving or simply
incapable, making it basically impossible in the incremental
deployment phase of ECN for RTP usage to determine this. If
additional information about the receivers and the network is known
it might be possible to deduce that a receiver is misbehaving. If it
can be determined that a receiver is misbehaving, the only response
is to exclude it from the RTP session and ensure that is does not
any longer have any valid security context to affect the
session.</t>
<t hangText="Misbehaving Senders:">The enabling of ECN gives the
media packets a higher degree of probability to reach the receiver
compared to not-ECT marked ones on a ECN capable path. However, this
is no magic bullet and failure to react to congestion will most
likely only slightly delay a network buffer over-run, in which its
session also will experience packet loss and increased delay. There
is some possibility that the media senders traffic will push other
traffic out of the way without being affected too negatively.
However, we do note that a media sender still needs to implement
congestion control functions to prevent the media from being badly
affected by congestion events. Thus the misbehaving sender is
getting a unfair share. This can only be detected and potentially
prevented by network monitoring and administrative entities. See
Section 7 of <xref target="RFC3168"></xref> for more discussion of
this issue.</t>
</list></t>
<t>We note that the end-point security functions needed to prevent an
external attacker from inferring with the signalling are source
authentication and integrity protection. To prevent information leakage
from the feedback packets encryption of the RTCP is also needed. For RTP
there exist multiple solutions possible depending on the application
context. <xref target="RFC3711">Secure RTP (SRTP)</xref> does satisfy
the requirement to protect this mechanism despite only providing
authentication if a entity is within the security context or not. <xref
target="RFC4301">IPsec</xref> and <xref target="RFC4347">DTLS</xref> can
also provide the necessary security functions.</t>
<t>The signalling protocols used to initiate an RTP session also need to
be source authenticated and integrity protected to prevent an external
attacker from modifying any signalling. Here an appropriate mechanism to
protect the used signalling needs to be used. For SIP/SDP ideally <xref
target="RFC5751">S/MIME</xref> would be used. However, with the limited
deployment a minimal mitigation strategy is to require use of <xref
target="RFC3261">SIPS (SIP over TLS)</xref> <xref
target="RFC5630"></xref> to at least accomplish hop-by-hop
protection.</t>
<t>We do note that certain mitigation methods will require network
functions.</t>
</section>
<section anchor="sec-examples" title="Examples of SDP Signalling">
<t>This section contain a few different examples of the signalling
mechanism defined in this specification in an SDP context. If there are
discrepancies between these examples and the specification text, the
specification text is definitive.</t>
<section title="Basic SDP Offer/Answer">
<t>This example is a basic offer/answer SDP exchange, assumed done by
SIP (not shown). The intention is to establish a basic audio session
point to point between two users.</t>
<t>The Offer:</t>
<figure>
<artwork><![CDATA[ v=0
o=jdoe 3502844782 3502844782 IN IP4 10.0.1.4
s=VoIP call
i=SDP offer for VoIP call with ICE and ECN for RTP
b=AS:128
b=RR:2000
b=RS:2500
a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh
a=ice-ufrag:9uB6
a=ice-options:rtp+ecn
t=0 0
m=audio 45664 RTP/AVPF 97 98 99
c=IN IP4 192.0.2.3
a=rtpmap:97 G719/48000/1
a=fmtp:97 maxred=160
a=rtpmap:98 AMR-WB/16000/1
a=fmtp:98 octet-align=1; mode-change-capability=2
a=rtpmap:99 PCMA/8000/1
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: ice rtp ect=0 mode=setread
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1000
a=rtcp-xr:ecn-sum
a=rtcp-rsize
a=candidate:1 1 UDP 2130706431 10.0.1.4 8998 typ host
a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr
10.0.1.4 rport 8998
]]></artwork>
</figure>
<t>This SDP offer offers a single media stream with 3 media payload
types. It proposes to use ECN with RTP, with the ICE based
initialization as being preferred over the RTP/RTCP one. Leap of faith
is not suggested to be used. The offerer is capable of both setting
and reading the ECN bits. In addition the RTCP ECN feedback packet is
configured and the RTCP XR ECN summary report. ICE is also proposed
with two candidates. It also supports reduced size RTCP and are
willing to use it.</t>
<t>The Answer:</t>
<figure>
<artwork><![CDATA[ v=0
o=jdoe 3502844783 3502844783 IN IP4 198.51.100.235
s=VoIP call
i=SDP offer for VoIP call with ICE and ECN for RTP
b=AS:128
b=RR:2000
b=RS:2500
a=ice-pwd:asd88fgpdd777uzjYhagZg
a=ice-ufrag:8hhY
a=ice-options:rtp+ecn
t=0 0
m=audio 53879 RTP/AVPF 97 99
c=IN IP4 198.51.100.235
a=rtpmap:97 G719/48000/1
a=fmtp:97 maxred=160
a=rtpmap:99 PCMA/8000/1
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: ice ect=0 mode=readonly
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1000
a=rtcp-xr:ecn-sum
a=candidate:1 1 UDP 2130706431 198.51.100.235 53879 typ host ]]></artwork>
</figure>
<t>The answer confirms that only one media stream will be used. One
RTP Payload type was removed. ECN capability was confirmed, and the
initialization method will be ICE. However, the answerer is only
capable of reading the ECN bits, which means that ECN can only be used
for RTP flowing from the offerer to the answerer. ECT always set to 0
will be used in both directions. Both the RTCP ECN feedback packet and
the RTCP XR ECN summary report will be used. Reduced size RTCP will
not be used as the answerer has not indicated support for it in the
answer.</t>
</section>
<section title="Declarative Multicast SDP">
<t>The below session describes an any source multicast using session
with a single media stream.</t>
<figure>
<artwork><![CDATA[ v=0
o=jdoe 3502844782 3502844782 IN IP4 198.51.100.235
s=Multicast SDP session using ECN for RTP
i=Multicasted audio chat using ECN for RTP
b=AS:128
t=3502892703 3502910700
m=audio 56144 RTP/AVPF 97
c=IN IP4 233.252.0.212/127
a=rtpmap:97 g719/48000/1
a=fmtp:97 maxred=160
a=maxptime:160
a=ptime:20
a=ecn-capable-rtp: rtp mode=readonly; ect=0
a=rtcp-fb:* nack ecn
a=rtcp-fb:* trr-int 1500
a=rtcp-xr:ecn-sum
]]></artwork>
</figure>
<t>In the above example, as this is declarative we need to require
certain functionality. As it is ASM the initialization method that can
work here is the RTP/RTCP based one. So that is indicated. The ECN
setting and reading capability to take part of this session is at
least read. If one is capable of setting that is good, but not
required as one can skip using ECN for anything one sends oneself. The
ECT value is recommended to be set to 0 always. The ECN usage in this
session requires both ECN feedback and the XR ECN summary report, so
their use is also indicated.</t>
</section>
</section>
<section title="Acknowledgments">
<t>The authors wish to thank the following persons for their reviews and
comments: Thomas Belling, Bob Briscoe, Roni Even, Thomas Frankkila,
Christian Groves, Cullen Jennings Tom Van Caenegem, Simo Veikkolainen,
Lei Zhu, and Christer Holmgren.</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc2762;
&rfc3168;
&rfc3550;
&rfc3611;
&rfc5234;
&rfc5245;
&rfc5348;
&rfc5389;
&icereg;
</references>
<references title="Informative References">
&rfc2974;
&rfc1112;
&rfc3261;
&rfc3264;
&rfc3540;
&rfc3551;
&rfc3569;
&rfc3711;
&rfc5751;
&rfc4301;
&rfc4340;
&rfc4347;
&rfc4566;
&rfc4585;
&rfc4588;
&rfc4607;
&rfc4960;
&rfc5124;
&rfc5506;
&rfc5630;
&rfc5760;
&no-op;
&rfc6189;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:00:05 |