One document matched: draft-westerlund-avt-ecn-for-rtp-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!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 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 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 rfc3711 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY rfc3851 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3851.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 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 no-op SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-avt-rtp-no-op-04.xml">
<!ENTITY rtcpssm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-avt-rtcpssm-18.xml">
<!ENTITY ice SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mmusic-ice-19.xml">
<!ENTITY zrtp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-zimmermann-avt-zrtp-15.xml">
<!ENTITY ecn-tunnel SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-tsvwg-ecn-tunnel-03.xml">
<!ENTITY sips SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-sip-sips-09.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-westerlund-avt-ecn-for-rtp-01"
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>Department 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="2" month="October" year="2009" />
<abstract>
<t>This document specifies how explicit congestion notification (ECN)
can be used with RTP/UDP flows that use RTCP as feedback mechanism.</t>
</abstract>
</front>
<middle>
<section anchor="sec-intro" title="Introduction">
<t>This document outlines how Explicit Congestion Notification (ECN)
<xref target="RFC3168"></xref> can be used for RTP <xref
target="RFC3550"></xref> flows running over UDP/IP which use RTCP as
feedback mechanism. The solution consists of feedback of ECN congestion
experienced markings to sender using RTCP, verification of ECN
functionality end-to-end, and how to initiate ECN usage. The initiation
process will have some dependencies on the signalling mechanism used to
establish the RTP session, a specification for mechanisms using SDP is
included.</t>
<t>ECN is getting attention as a method to minimise the impact of
congestion on real-time multimedia traffic. When ECN is used, the
network can signal to applications that congestion is occurring, whether
that congestion is due to queuing at a congested link, limited resources
and coverage on a radio link, or other reasons. This congestion signal
allows applications to reduce their transmission rate in a controlled
manner, rather than responding to uncontrolled packet loss, and so
improves the user experience while benefiting the network.</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 that
sender that ECN marked packets are being received, so it can respond to
the congestion. <xref target="RFC3168">TCP</xref>, <xref
target="RFC4960">SCTP</xref> and <xref target="RFC4340">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 mechanism directly in UDP.
Instead the protocol on top of UDP needs to provide that feedback, which
for RTP is 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>. The means by
which ECN is used with RTP over UDP is defined in <xref
target="sec-definition"></xref>, along with RTCP extensions for ECN
feedback in <xref target="sec-rtcp-ecn"></xref>. In <xref
target="sec-rtcp-translator-mixer"></xref> we discuss how RTCP ECN
feedback 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 the 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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref target="RFC2119">
RFC 2119</xref>.</t>
<t>Abbreviations <list style="hanging">
<t hangText="ECN:">Explicit Congestion Notification</t>
<t hangText="ECT:">ECN Capable Transport</t>
<t hangText="ECN-CE:">ECN Congestion Experienced</t>
<t hangText="not-ECT:">Not ECN Capable Transport</t>
</list></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 Congestion
Experienced (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
some cases).</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 ASM, although a recent extension supports SSM with
unicast feedback).</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. Indeed, in many ways,
ECN support is more important for RTP sessions, since 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 a voice telephony.</t>
<section title="Requirements">
<t>Considering ECN and these protocols one can create a set of
requirements that must be satisfied to at least some degree if ECN is
used by an other protocol (such as RTP over UDP) <list style="symbols">
<t>REQ 1: A mechanism to negotiate and initiate the usage of ECN
for RTP/UDP/IP sessions is required</t>
<t>REQ 2: A mechanism to feedback the reception of any packets
that are ECN-CE marked to the packet sender is required</t>
<t>REQ 3: Provide mechanism to minimise the possibility for
cheating is desirable</t>
<t>REQ 4: Some detection and fallback mechanism is needed 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 meet
for RTP over UDP.</t>
</section>
<section 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, all of which need to be
verified to support ECN before it can be used.</t>
<t>The usage 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 at the sender by changing the media encoding, at
the receiver by changing the subscription to a layered encoding, or in
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 with potentially several active senders and
multicast RTCP feedback, or a source specific multicast (SSM)
group 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="I-D.ietf-avt-rtcpssm"></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. Note that group membership may change during the lifetime of
a multicast RTP session, potentially introducing new receivers
that are not ECN capable. Senders must use the mechanisms
described in <xref target="sec-ecn-failure"></xref> to monitor
that all receivers continue to support ECN, and needs to fallback
to non-ECN use if they 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
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 zero out the ECN bits 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 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.</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>: 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, and should be ECT marked
if any of the incoming packets are ECT marked. When RTCP ECN
feedback packets (<xref target="sec-rtcp-ecn"></xref>) are
received, they must be rewritten to match the modifications
made to the media stream (see <xref
target="sec-rtcp-ecn-translator"></xref>).</t>
<t>If the translator is a media transcoder, 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:">This 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. 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 connections 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.</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 cannot 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 RTP session can be
adapted in a number of ways, such as media sender using TFRC <xref
target="RFC5348"></xref> or other algorithms, or for multicast
sessions either a sender based scheme with lowest common rate, or
receiver driven mechanism based on layers to support more
heterogeneous paths.</t>
<t>To ensure timely feedback of CE marked packets, 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>
<t>The control of which RTP data packets are marked as ECT, and
whether ECT(0) or ECT(1) is used, is due to the sender. RTCP packets
must not be ECT marked, whether generated by sender or receivers.</t>
</section>
</section>
<section anchor="sec-definition" title="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 makes the solution work:</t>
<t><list style="numbers">
<t>Negotiation of the capability to use ECN with RTP/UDP</t>
<t>Initiation and initial verification of ECN capable transport</t>
<t>Ongoing use of ECN within an RTP session</t>
<t>Failure detection, verification and fallback</t>
</list> Before an RTP session can be created, a signalling protocol is
used to discover the other participants and negotiate session parameters
(see <xref target="sec-signalling"></xref>). One of the parameters that
can be negotiated is the capability of a participant to support ECN
functionality, or otherwise. 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 support ECN (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 ECN
capability, it must verify if that capability is usable. There are three
ways in which this verification phase may be done (<xref
target="sec-initiation"></xref>): <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 of each
other. If a new receiver joins an existing session it also needs to
verify ECN support. If verification fails the sender needs to stop
using ECN. As the sender will not know of the receiver prior to it
sending RTP or RTCP packets, the sender will wait for the first RTCP
packet from the new receiver to determine if that contains ECN
feedback or not.</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. If successful the path's
capability to convey ECN marked packets is verified. A new STUN
attribute is defined to convey feedback that the ECT marked request
was received.</t>
<t>Thirdly, make a leap of faith that it will work. This is only
recommended in applications that know they run in controlled
environments where ECN functionality through other means have been
verified. In this mode one assumes ECN to work and then reacts to
failure indicators if the assumption proved wrong. The usage of this
method relies on a high confidence in successful ECN function or an
application where failure are not serious. However, also the impact
on the network and other users must be considered. Thus there are
limitation to when this method is allowed.</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 remarks ECT marked packets
to non-ECT, possibly marking packets with a CE mark as non-ECT. This can
force the network into heavy congestion due to non-responsiveness, and
seriously impact media quality.</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 feedback any CE marks to the sender using RTCP in
RTP/AVPF immediate or early feedback mode (see <xref
target="sec-ongoing"></xref>). An RTCP feedback report is sent as soon
as possible by the transmission rules for feedback that are in place.
This feedback report indicates new CE marks since last ECN feedback
packet and also the number of new CE marks through a accumulative sum.
This is the mechanism to provide the fastest possible feedback to
senders about CE marks. On receipt of a CE marked packet, the system
must react to congestion as-if packet loss has been reported.</t>
<t>This rapid feedback is not optimised for reliability, therefore an
additional procedure is used to ensure more reliable, but less timely,
reporting of the ECN information. An ECN summary report should also be
sent in regular RTCP reports. The ECN summary report contains the same
information as the ECN feedback format, only packed differently for
better efficiency with large reports. By using accumulative counters for
seen CE, ECT, not-ECT or packet loss the sender can determine what
events has happened since the last report, independently of any RTCP
packets having been lost.</t>
<t>RTCP traffic must not be ECT marked for the following reason. ECT
marked traffic may be dropped if the path is not ECN compliant. As RTCP
is used to provide feedback about what has been transmitted and what ECN
markings that are received it is important that these are 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 remarking 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. Both the RTCP ECN summary reports
and the ECN feedback packets allow the sender to compare the number of
ECT(0), ECT(1), and non-ECT marked packet with those that were sent,
while also reporting CE marked and lost packets. If these numbers do not
agree with what was sent, it can be inferred that the path does not
reliably pass ECN-marked packets. More detailed discussions are
presented in <xref target="sec-ecn-failure"></xref> and <xref
target="sec-interpret"></xref> on how to interpret different cases. A
sender detecting a possible ECN non-compliance issue should then stop
sending ECT marked packets to determine if that allows the packet to be
correctly delivered. If the issues can be connected to ECN, then ECN
usage is suspended and possibly also re-negotiated.</t>
<t>This specification offers an option of computing and reporting an ECN
nonce over all received packets that where not ECN-CE marked or reported
explicitly lost. Thus, the sender will have an additional tool to detect
if any remarking happens. It can also based on statistics detect
receivers that suppress reporting of CE marked packets, i.e. detect
cheating. The incentive for a real-time application to cheat in its ECN
reporting is less than for TCP, as increased congestion levels are
likely to cause packet losses that decrease the media quality. While for
TCP lying allows for keeping a larger congestion window than compliant
receivers and any packet losses will be corrected by TCP's
retransmission. The ECN nonce mechanism also requires more data to
function correctly. To enable the sender to verify the ECN nonce, the
sender must learn the sequence number of all packets that was either CE
marked or lost. Otherwise it can't correctly exclude these packet from
the ECN nonce sum. This is done using a RTCP XR Nonce report, containing
the nonce sums and indicating the lost or ECN-CE marked packets using a
run length encoded bit-vector. Thus ECN nonce has a higher demand for
RTCP bandwidth. Combined with the reduced incentive to cheat, this
mechanism is optional and is only recommended for applications where the
incentive might be higher, such as streaming with retransmissions.</t>
<t>In the detailed specification of the behaviour below, the different
functions the general case will first be discussed. In cases special
considerations are needed for middleboxes, multicast usage etc, those
will be specially discussed in related subsections.</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. This includes negotiating if ECN is to be
used symmetrically, the method for initial ECT verification, and
whether the ECN nonce is to be used. This memo defines the mappings of
this information onto SDP both for declarative and offer/answer usage.
There are one SDP extension to indicate if ECN support should be used
and the method for initiation. In addition there are an ICE parameter
to indicate that ECN initiation using STUN as part of an ICE exchange
is supported.</t>
<t>An RTP system that supports ECN and uses SDP in the signalling MUST
implement the SDP extension to signal ECN capability as described in
<xref target="sec-sdp-ecn"></xref>. It MAY also implement alternative
ECN capability negotiation schemes, such as the ICE extension
described in <xref target="sec-ice-ecn"></xref>.</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, which 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 for ECN initiation to be
used in the session. Thus the attribute take a list of methods for
initiation, which are 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>In addition, a number of OPTIONAL parameters may be included in
the "a=ecn-capable-rtp" attribute as follows:</t>
<t><list style="symbols">
<t>The "mode" parameter signals the endpoint's capability to set
and read ECN marks in UDP packets. An examination of various
operating systems has shown that end-system support for ECN
marking of UDP packets may be symmetric or asymmetric. By this
we mean that some systems may allow end points to set the ECN
bits in an outgoing UDP packet but not read them, while others
may allow applications to read the ECN bits but not set them.
This either/or case may produce an asymmetric support for ECN
and thus should be conveyed in the SDP signalling. The
"mode=setread" state is the ideal condition where an endpoint
can both set and read ECN bits in UDP packets. The
"mode=setonly" state indicates that an endpoint can set the ECT
bit, but cannot read the ECN bits from received UDP packets to
determine if upstream congestion occurred. The "mode=readonly"
state indicates that the endpoint can read the ECN bits to
determine if downstream congestion has occurred, but it cannot
set the ECT bits in outgoing UDP packets. When the "mode="
parameter is omitted it is assumed that the node has "setread"
capabilities. This option can provide for an early indication
that ECN cannot be used in a session. This would be case when
both the offerer and answerer set the "mode=" parameter to
"setonly" or "readonly", or when an RTP sender entity considers
offering "readonly".</t>
<t>The "nonce" parameter may be used to signal whether the ECN
nonce is to be used in the session. This parameter takes two
values; "nonce=1" for nonce proposed or shall be used, and
"nonce=0" for no nonce.</t>
<t>The "ect" parameter makes it possible to express the
preferred ECT marking. This is either random (default), ECT(0)
or ECT(1). If the ECN nonce is used then this parameter MUST be
ignored, and random ECT is implied. The "ect" parameter
describes a receiver preference, and is useful in the case where
the receiver knows it is behind a link using IP header
compression, the efficiency of which would be seriously
disrupted if it were to receive packets with randomly chosen ECT
marks.</t>
</list></t>
<t>The <xref target="RFC5234">ABNF</xref> grammar for the
"a=ecn-capable-rtp" attribute is as follows:</t>
<t><figure>
<artwork><![CDATA[ecn-attribute = "a=ecn-capable-rtp" init-list parameter-list
init-list = init-value *("," init-value)
init-value = "rtp" / "ice" / "leap" / init-ext
init-ext = token
parameter-list = *(SP ";" par-value)
par-value = nonce / mode / ect / (parameter "=" value)
mode = "mode=" ("setonly" / "setread" / "readonly")
nonce = "nonce=" ("0" / "1")
ect = "ect=" ("random" / "0" / "1")
parameter = token
value = token / quoted-string
token = 1*(%x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39 /
%x41-5A / %x5E-7A / %x7C / %x7E)
quoted-string = ( DQ *qdtext DQ )
qdtext = %x20-21 / %x23-7E / %x80-FF
DQ = %x22 ; US-ASCII double-quote mark (34)
]]></artwork>
</figure></t>
<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 flow 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 some 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 in the media sections of the answer. If there
is no matching initiation method capability, or if the receiver does
not wish to attempt to use ECN in the session, it does not include
an "a=ecn-capable-rtp" attribute in its answer. If the attribute is
removed then ECN MUST NOT be used in any direction for that media
flow. The answer may also include optional parameters, as discussed
below.</t>
<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.</t>
<!--MW: We will need to revisit the above definition due to multicast sessions where there
might be multiple senders but the offer/answer goes point to point. -->
<t>If the "nonce=1" parameter is present in the "a=ecn-capable-rtp"
attribute of the offer, the answer MUST explicitly include the
"nonce=" parameter in the "a=ecn-capable-rtp" attribute of the
answer to indicate if it supports the ECN nonce. If the answer
indicates support ("nonce=1") then ECN nonce SHALL be used in the
session; if the answer does not include the "nonce=" parameter, or
includes "nonce=0", then the ECN nonce SHALL NOT be used. The answer
MAY include a "nonce=0" parameter in an answer even if not included
in the offer. This indicates that the answerer supports and is
interested in using ECN-nonce in this session, but it is not
currently enabled. If the offerer supports use of the nonce then it
SHOULD run a second round of offer/answer to enable use of the ECN
nonce.</t>
<!-- One of the uses of the ECN nonce is to detect cheating receivers, yet we
allow them to decline to use it? (csp)
MW: I think we need to allow negoitation. It it is the application that should demand
that nonce is enabled if required.-->
<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 behaviour of the answering party, and
its value in the answer indicates a preference for the behaviour of
the offering party. It will be the senders choice if to honor the
receivers preference or not.</t>
<t>When SDP is used in a declarative manner, for example in a
multicast session using SAP, 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 understand ECN-marked UDP
packets, implement the method of initiation, and can generate RTCP
ECN feedback (note that having the capability to use ECN doesn't
necessarily imply that the underlying network path between sender
and receiver supports ECN). If the nonce parameter is included the
ECN nonce shall be used in the session. The mode parameter MAY be
included also in declarative usage, to indicate which capability is
required by the consumer of the SDP. So for example in a SSM session
the participants configured with a particular SDP will all be in a
media receive only mode, thus mode=readonly will work as the
capability of reporting on the ECN markings in the received is what
is required.</t>
<!-- The above is not sufficient. It needs to discuss the "mode=" parameter for
the declarative SDP. Does it make sense to offer "mode=readonly" here, for example? (csp)
Piers: I think its possible to use either but with the constraint added above..?
-->
<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, in order that
the sender can react to ECN-CE marked packets. Thus, the use of the
Extended RTP Profile for RTCP-Based Feedback (RTP/AVPF) <xref
target="RFC4585"></xref> MUST be signalled.</t>
<t>When using ECN nonce, the RTCP XR signalling indicating the ECN
Nonce report MUST also be included in the SDP following <xref
target="RFC3611"></xref>.</t>
</section>
<!--I am uncertain if this next sub section is truly needed. We need to figure out if we would cause any
issues by not explictly signalling the capability also in the ICE options attribute. -->
<section anchor="sec-ice-ecn"
title="ICE Parameter to Signal ECN Capability">
<t>One new ICE <xref target="I-D.ietf-mmusic-ice"></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 this initiation method (<xref
target="sec-stun-init-ecn"></xref>) actually is going to be used, it
is explicitly negotiated using the "a=ecn-capable-rtp"
attribute.</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-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.</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 its destination(s). There is some risk
that the usage of ECN will result in either reset of the ECN field or
loss of all packets with ECT or ECN-CE markings. If the path between
the sender and the receiver 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
during both the initiation and full usage of ECN with RTP. This is to
ensure that packet loss due to ECN marking will not effect the RTCP
traffic and the necessary feedback information.</t>
<t>An RTP system that supports ECN MUST implement the initiation of
ECN using 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 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 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 network to support 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 fraction of its traffic with ECT marks to act
a 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. An RTP sender is RECOMMENDED to send a
minimum of two packets with ECT markings per RTCP reporting
interval, one with ECT(0) and one with ECT(1), and will continue
to send some ECT marked traffic as long as the ECN initiation
phase continues. The sender SHOULD NOT mark all RTP packets as
ECT during the ECN initiation phase.</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 usage
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 duplicated in transmission, since
their 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 participants in the
session MUST listen for ECT or ECN-CE marked RTP packets, and
generate RTCP ECN feedback packets (<xref
target="sec-rtcp-ecn"></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 contain an ECN summary
report (<xref target="sec-ecn-summary-report"></xref>).
Reception of any ECN-CE marked packets SHOULD also result in
additional early or immediate feedback packet with the ECN
feedback packet.</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 becomes stable, provided
all known participants have sent one or more RTCP ECN feedback
packets 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 a single RTCP ECN
feedback report indicating successful receipt of the ECT-marked
packets, with no negative indications, from a single RTP
receiver. 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 is
any other participants in the session. If other participants are
detected, 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. <list
style="empty">
<t>Note: One use case that requires further consideration is
a unicast connection with several SSRCs multiplexed onto the
same flow (e.g. SVC video using SSRC multiplexing for the
layers). It is desirable to be able to rapidly negotiate ECN
support for such a session, but the optimisation above fails
since the multiple SSRCs make it appear that this is a group
communication scenario. It's not sufficient to check that
all SSRCs map to a common RTCP CNAME to check if they're
actually located on the same device, because there are
implementations that use the same CNAME for different parts
of a distributed implementation.</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>
<t>The reception of RTCP ECN feedback packets that indicate
greatly increased packet loss rates for ECT marked packets,
compared to non-ECT marked packets, is a strong indication of
problems with ECN support on the network path. Senders MAY
consider such reports as indications that they should not use
ECN on the path, even though some ECT-marked packets do reach
all receivers.</t>
<t>The sender must also watch for cases where ECT packets has
been remarked, for example to not-ECT, either explicitly
reported in an ECN feedback packet, or implicit due to a
receiver not including the ECN feedback format in its regular
report.</t>
</list></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 ECN capable path prior to media
transmission. This method is considered in the context where the
session participants are using <xref
target="I-D.ietf-mmusic-ice">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>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, and provided
the chosen candidate is not a relayed address, one performs an
additional connectivity check including the here defined STUN
attribute "ECT Check" and in an IP/UDP packet that are ECT marked.
The STUN server will upon reception of the packet note the received
ECN field value and in its response send an IP/UDP/STUN Packet with
ECN field set to not-ECT and also include the ECN check STUN
attribute.</t>
<t>The STUN ECN check STUN attribute contains one field and a flag.
The flag indicate if the echo field contains a valid value or not.
The field is the ECN echo field, and when valid contains the two ECN
bits from the packet it echoes back. The ECN check STUN attribute is
an 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 filed 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 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 STUN server receiving a request with the ECN
Check attribute which understand it 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.</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). It is not generally
recommended as the impact on both the application and the network
may be substantial. Applications may experience high packet loss
rates, this is both from dropped ECT marked packets, and the result
of driving the network into higher degrees of congestion by not
being responsive to ECN marks. The network may experience higher
degrees of congestion due to the unresponsiveness of the sender due
to lost ECN-CE marks from non-compliant remarking.</t>
<t>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.</t>
<t>Not sending any RTP packets as not-ECT in the case of
non-compliant node dropping ECT marked traffic the RTP receiver will
not get any baseline packets to ensure that it treat this SSRC as an
active sender. Thus the failure to include the sender in its RTCP
sender or receiver packets report block becomes the indicator for
this case. This is blunter than a receiver report block that
indicates explicitly how many packets actually has been lost. The
sender should be aware that in unicast or under AVPF transmission
rules the first RTCP packet may come immediately upon joining or
already after 500 ms. Thus, triggering on reports without any report
blocks, cannot be done reliably on the first RTCP report received
from a new SSRC. Thus delaying detection of lack of functionality
substantially until a second report comes in.</t>
<t>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>
</section>
<section title="ECN Nonce during initiation">
<t>ECN Nonce if enabled SHALL be used during initiation the same way
as ECN nonce is used under ongoing use of ECN as described in <xref
target="sec-nonce-report"></xref>.</t>
</section>
</section>
<section anchor="sec-ongoing"
title="Ongoing Use of ECN Within an RTP Session">
<t>Once ECN usage has been successfully initiated for an RTP sender,
that sender begins sending all RTP data packets as ECT-marked, and its
receivers continue sending 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 usage, it SHOULD
mark all the RTP data packets it sends as ECT. The choice between
ECT(0) and ECT(1) is determined by the sender having considered the
preferencies expressed by the "ect" parameter in the
"a=ecn-capable-rtp" attribute. If the sender selects a random choice
of ECT marking, the sender MUST record the statistics for the
different ECN values sent. If ECN nonce is activated the sender must
record the value and calculate the ECN-nonce sum for outgoing
packets <xref target="RFC3540"></xref> to allow the use of the
ECN-nonce to detect receiver misbehaviour (see <xref
target="sec-ecn-failure"></xref>). Guidelines on the random choice
of ECT values are provided in Section 8 of <xref
target="RFC3540"></xref>.</t>
<t>The sender SHALL NOT include ECT marks on outgoing RTCP packets,
and SHOULD NOT include ECT marks on any outgoing control messages
(e.g. <xref target="RFC5389">STUN</xref> packets, <xref
target="RFC4347">DTLS</xref> handshake packets, or <xref
target="I-D.zimmermann-avt-zrtp">ZRTP</xref> control packets, that
are multiplexed on the same UDP port).</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 to report this back to
the sender. The feedback RTCP packet sent SHALL consist at least one
ECN feedback packet (<xref target="sec-rtcp-ecn"></xref>) reporting
on the packets received since the last ECN feedback packet, and
SHOULD contain an RTCP SR or RR packet. 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. ECN Nonce
information SHOULD NOT be included in early or immediate reports,
only when regular reports are sent.</t>
<t>Every time a regular compound RTCP packet is to be transmitted,
the RTP receiver MUST include an RTCP XR ECN summary report <xref
target="sec-ecn-summary-report"></xref> as part of the compound
packet. If ECN-nonce is enabled the receiver MUST also include an
RTCP XR Nonce report packet <xref target="sec-rtcp-xr-ce"></xref>.
It is important to configure the RTCP bandwidth (e.g. using an SDP
"b=" line) such that the bit-rate is sufficient for a usage that
includes ECN-CE events.</t>
<t>The multicast feedback implosion problem, that occurs when many
receivers simultaneously send feedback to a single sender, must also
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 reasonably timely, allowing the
sender to react on a single or a few reports. <list style="empty">
<t>An open issue is whether we should employ some form of
feedback suppression on ECN-CE feedback for groups? If one can
make an assumption that a sender will react on a few ECN-CE
marks then suppression could be employed successfully and reduce
the RTCP bandwidth usage.</t>
</list></t>
<t>In case a receiver driven congestion control algorithm is to be
used and has through signalling been agreed upon, the algorithm MAY
specify that the immediate scheduling (and later transmission) of
ECN-CE feedback of any received ECN-CE mark is not required and
shall not be done. In that case ECN feedback is only sent using
regular RTCP reports for verification purpose and in response to the
initiation process ("rtp") of any new media senders as specified in
<xref target="sec-rtp-init-ecn"></xref>.</t>
<section anchor="sec-nonce-report" title="ECN Nonce Reporting">
<t>ECN Nonce reporting requires both the ECN nonce sum and the
sequence numbers for packets where the ECN marking has been lost.
This information is variable size as it depends on both the total
number of packet sent per reporting interval and the CE and Packet
loss pattern how many bits are required for reporting.</t>
<t>The RTCP packets may be lost, and to avoid the possibility for
cheating by "losing" the Nonce information for where one is
cheating the nonce coverage needs to be basically complete. Thus
the Nonce reporting SHOULD cover at least the 3 regular reporting
intervals. The only exception allowed is if the reporting
information becomes to heavy and makes the RTCP report packet
become larger than the MTU. In that case a receiver MAY reduced to
coverage for the ECN nonce to only the last or two last reporting
intervals. A sender should consider the received size report for
cases where the coverage is not at least three reporting intervals
and determine if this may be done to cheat or not. Failure to have
reported on all intervals MAY be punished by reducing the
congestion safe rate.</t>
<t>The ECN nonce information in the ECN feedback packet consists
of both a start value for the nonce prior to the first packet in
the reporting interval and the final 2-bit XOR sum over all the
received ECN values, both not-ECT and ECT for the report interval.
The report interval is explicitly signalled in the RTCP XR Nonce
report packet. The initial value for the Nonce is 00b.</t>
</section>
</section>
<section anchor="sec-congestion"
title="Response to Congestion Notifications">
<t>When RTP packets are received with ECN-CE marks, the sender
and/or receivers MUST react with congestion control as-if those
packets had been lost. 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 may
be 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 on it as if
it was packet losses that 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 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 packet to check if it experiences
congestion at 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 ECN
feedback 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 feedback is sufficient
(without using RTP/AVPF immediate or early feedback).</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 in
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 having to settle for the lowest common rate.</t>
<t><list style="empty">
<t>Note: There are many additional references that may be cited
here. If this document is accepted as an AVT work item, some
discussion of the appropriate amount of detail to include here
would be worthwhile.</t>
</list></t>
<t>We note that ECN support is not a silver bullet to improving
performance. The use of ECN gives the change 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 and Receiver Misbehaviour">
<t>ECN-nonce is defined in RFC3540 as a means to ensure that a TCP
clients does not mask ECN-CE marks, this assumes that the sending
endpoint (server) acts on behalf of the network.</t>
<t>The assumption about the senders acting on the behalf of the
network may be reduced due to the nature of peer-to-peer usage. Still
a large part of RTP senders are infrastructure devices that do have an
interest in protecting both service quality and the network. In
addition as real-time media commonly is more sensitive to increased
delay and packet loss it will be in both media sender and receivers
interest to minimise the number and duration of any congestion events
as it will affect media quality.</t>
<t>In addition ECN with RTP can suffer from path changes resulting in
that a non ECN compliant node becomes part of the path. That node may
perform either of two actions that has effect on the ECN and
application functionality. The gravest is if the node drops packets
with any ECN field values other than 00b. This can be detected by the
receiver when it receives a RTCP SR packet indicating that a number of
packets has not been received. The sender may also detect it based on
the receivers RTCP RR packet where the extended sequence number is not
advanced due to the failure to receive packets. If the 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 remark a packet from ECT 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 ECN feedback packet allows the sender to compare the number of
ECT marked packets of different type with the number it actually sent.
The number of ECT packets received plus the number of CE marked and
lost packets should correspond to the number of sent ECT marked
packets. If this number doesn't agree there are two likely reasons, a
translator changing the stream or not carrying the ECN markings
forward or that some node remarks 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 happing 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 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 to report this to the sender that includes at least
the RTCP RR and the ECN feedback message. Thus speeding up the
detection at the sender of the losses and thus triggering sender
side mitigation.</t>
<t>A Sender that detects high packet loss rates for its RTP packet
flow while sending them marked as ECT, SHOULD immediately remark
them as not-ECT to determine if the losses potentially are due to
the ECT markings. If the losses disappear with the remarking, 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 are ECN capable.</t>
<t>Renegotiating the session to disable ECN support. A choice
that is suitable if the impact of ECT probing on the media
quality are noticeable. If multiple initiations has 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:</t>
<t><list style="symbols">
<t>Video switching MCU or similar middleboxes that selects to
deliver media from the sender only intermittently.</t>
<t>Load balancing devices may in worst case result in that some
packets take a different network path then the others.</t>
<t>Mobility solutions that switches underlying network path in a
transparent way for the sender or receiver.</t>
<t>Membership changes in a multicast group.</t>
</list></t>
</section>
<section anchor="sec-interpret"
title="Interpretation of ECN Summary information">
<t>This section contains discussion on how you can use the ECN
summary report information in detecting various types of ECN path
issues. Lets start to review the information the reports provide on
a per source (SSRC) basis:</t>
<t><list style="hanging">
<t hangText="CE Counter:">The number of RTP packets received so
far in the session with an ECN field set to CE (11b).</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 (10b / 01b).</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
(00b)</t>
<t hangText="Packet loss counter:">The number of RTP packets
that are expected minus the number received.</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 initiated to zero they provide value
for the RTP stream sender from the very first report. After the
first report the changes between the latest received and the
previous one is determined by simply taking the values of the latest
minus the previous one, taking field wrapping into account. This
definition is also robust to packet losses, as if one report is
missing, the period for which the information is covering becomes
longer, but otherwise equally valid.</t>
<t>In a perfect world the number of not-ECT received should be equal
to the number sent minus some fraction of the lost packets, and the
sum of the ECT, CE should be equal to the number ECT marked sent
minus a fraction of the lost packets. There are however two sources
of uncertainty in this, number of packet losses, and packet
duplication. Packet loss and packet duplication can change the
distribution between ECT(0), ECT(1) and not-ECT. This by having for
example a ECT (0) packet being lost, and then a ECT(1) packet being
duplicated and counted as two, thus making the ECT(1) counter become
one bigger and the ECT(0) one less than expected. To avoid these
issues it is recommended that suppression of duplicate packets are
performed before gathering this statistics.</t>
<t>The level of packet duplication included in the report can be
estimated from the sum over all of fields counting received packets.
A high level of packet duplication increases the insecurity in the
statistics and firm conclusions becomes more difficult and requires
clearer statics.</t>
<t><list style="hanging">
<t hangText="Detecting clearing of ECN field:">If the ratio
between ECT and not-ECT transmitted in the reports has become
all not-ECT or substantially changed towards not-ECT then this
is clearly indication that the path results in clearing of the
ECT field.</t>
<t hangText="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.</t>
<t></t>
</list></t>
<t></t>
</section>
<section title="Using ECN-nonce">
<t>This document offers ECN Nonce as a method of strengthening both
the detection of failures and enable senders to verify the receiver
behavior. We note that it appears quite counter productive for a
receiver to attempt to cheat as it most likely will have negative
impact on its media quality. However, certain usages of RTP may
result in a situation that is more similar to TCP, i.e. where packet
losses are repaired and a higher bit-rate is desirable. Thus RTP
sessions that use repair mechanisms as FEC or retransmission may
consider the usage of the ECN nonce to prevent cheating.</t>
</section>
</section>
</section>
<section anchor="sec-rtcp-ecn" title="RTCP Extensions for ECN feedback">
<t>This documents defines three different RTCP extensions. One AVPF NACK
Transport feedback format for urgent ECN information. One RTCP XR ECN
summary report block type for regular reporting of the ECN marking
information. And one additional RTCP XR report block type for ECN
nonce.</t>
<section title="ECN Feedback packet">
<t>This AVPF NACK feedback format is intended for usage in AVPF early
or immediate feedback modes when information needs to urgently reach
the sender. Thus its main usage is upon reception of a ECN-CE marked
RTP packet, or during the initiation procedures to speed that up. The
feedback format is also defined with <xref target="RFC5506">reduced
size RTCP</xref> in mind. In reduced size RTCP feedback packets may be
sent without accompanying Sender or Receiver Reports that would
contain the Extended Highest Sequence number and the accumulated
number of packet losses. Both are important for the ECN functionality
to verify functionality and keep track of when CE marking does
occur.</t>
<t>The RTCP packet starts with the common header defined by <xref
target="RFC4585">AVPF</xref> which is reproduced here for the readers
information:</t>
<figure anchor="fig-avpf-common" title="AVPF Feedback common 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|V=2|P| FMT | PT | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of packet sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of media source |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: Feedback Control Information (FCI) :
: :
]]></artwork>
</figure>
<t>From <xref target="fig-avpf-common"></xref> it can be determined
the identity of the feedback provider and for which RTP packet sender
it applies. Below is the feedback information format defined that is
inserted as FCI for this particular feedback messages that is
identified with an FMT value=[TBA1].</t>
<figure anchor="fig-ecn-feedback" title="ECN Feedback 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 | Lost packets counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter | ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure>
<t>The FCI information for the <xref target="fig-ecn-feedback">ECN
Feedback format</xref> are the following:</t>
<t><list style="hanging">
<t hangText="Extended Highest Sequence Number:">The least
significant 20-bit from an Extended highest sequence number
received value as defined by <xref target="RFC3550"></xref>. Used
to indicate for which packet this report is valid upto.</t>
<t hangText="Lost Packets Counter:">The total number of RTP
packets from this SSRC the receiver that it expected minus the
number of received, see <xref target="RFC3550">Section 6.4.1
of</xref> for the normative definition. This representation is
done using 12-bit signed representation, compared to 24-bit in
RTCP SR or RR packets. It is important to ensure that the wrapping
is handled correctly.</t>
<t hangText="CE Counter:">The total number of RTP packets from
this SSRC the receiver has received since the receiver joined the
RTP session that had an ECN field value of CE. The receiver should
keep track of this value using a local representation that is
longer than 16-bits, and only include the 16-bits with least
significance. In other words, the field will wrap to 0 if more
than 65535 packets has been received.</t>
<t hangText="ECT (0) Counter:">The total number of RTP packets
from this SSRC the receiver has received since the receiver joined
the RTP session that had an ECN field value of ECT (0). The
receiver should keep track of this value using a local
representation that is longer than 16-bits, and only include the
16-bits with least significance. In other words, the field will
wrap if more than 65535 packets has been received.</t>
<t hangText="ECT (1) Counter:">The total number of RTP packets
from this SSRC the receiver has received since the receiver joined
the RTP session that had an ECN field value of ECT (1). The
receiver should keep track of this value using a local
representation that is longer than 16-bits, and only include the
16-bits with least significance. In other words, the field will
wrap if more than 65535 packets has been received.</t>
<t hangText="not-ECT Counter:">The total number of RTP packets
from this SSRC the receiver has received since the receiver joined
the RTP session that had an ECN field value of not-ECT. The
receiver should keep track of this value using a local
representation that is longer than 16-bits, and only include the
16-bits with least significance. In other words, the field will
wrap if more than 65535 packets has been received.</t>
</list>Each FCI reports on a single source. Multiple sources can be
reported by including multiple RTCP feedback messages in an compound
RTCP packet. The AVPF common header indicates both the sender of the
feedback message and on which stream it relates to.</t>
<t>The Counters SHALL be initiated to 0 for a new receiver. This to
enable detection of CE or Packet loss already on the initial report
from a specific participant.</t>
<t>The Extended Highest sequence number and packet loss fields are
both truncated in comparison to the RTCP SR or RR versions. This is to
save bits as the representation is redundant unless reduced size RTCP
is used in such a way that only feedback packets are transmitted, with
no SR or RR in the compound RTCP packet. Due to that regular RTCP
reporting will include the longer versions of the fields the wrapping
issue will be less unless the packet rate of the application is so
high that the fields will wrap within a regular RTCP reporting
interval. In those case the feedback packet need to be sent in a
compound packet together with the SR or RR packet.</t>
<t>There is an issue with packet duplication in relation to the packet
loss counter. If one avoids holding state for which sequence number
has been received then the way one can count loss is to count the
number of received packets and compare that to the number of packets
expected. As a result a packet duplication can hide a packet loss. If
a receiver is tracking the sequence numbers actually received and
suppresses duplicates it provides for a more reliable packet loss
indication. Reordering may also result in that packet loss is reported
in one report and then removed in the next.</t>
<t>The CE counter is actually more robust for packet duplication.
Adding each received CE marked packet to the counter is not an issue.
If one of the clones was CE marked that is still a indication of
congestion. Packet duplication has potential impact on the ECN
verification. Thus the sum of packets reported may be higher than the
number sent. However, most detections are still applicable.</t>
</section>
<section anchor="sec-ecn-summary-report"
title="RTCP XR Report block for ECN summary information">
<t>This report block combined with RTCP SR or RR report blocks carries
the same information as the ECN Feedback Packet and shall be based on
the same underlying information. However, there is a difference in
semantics between the feedback format and this XR version. Where the
feedback format is intended to report on a CE mark as soon as
possible, this extended report is for the regular RTCP report and
continuous verification of the ECN functionality end-to-end.</t>
<t>The ECN Summary report block consists of one report block
header:<figure>
<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 | Reserved | Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
<t>and then followed of one or more of the following report data
blocks:</t>
<t><figure>
<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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE Counter | not-ECT Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ECT (0) Counter | ECT (1) Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
</figure></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 Lenght:">The length of the report block. Used
to indicate the number of report data blocks present in the ECN
summary report. This length will 3*n, where n is the number of
data blocks, i.e. 3 for one data block, 6 for two, etc.</t>
<t hangText="SSRC of Media Sender:">The SSRC identifying the media
sender this report is for.</t>
<t hangText="CE Counter:">The total number of RTP packets from
this SSRC the receiver has received since the receiver joined the
RTP session that had an ECN field value of CE. The receiver should
keep track of this value using a local representation that is
longer than 16-bits, and only include the 16-bits with least
significance. In other words, the field will wrap if more than
65535 packets has been received.</t>
<t hangText="not-ECT Counter:">The total number of RTP packets
from this SSRC the receiver has received since the receiver joined
the RTP session that had an ECN field value of not-ECT. The
receiver should keep track of this value using a local
representation that is longer than 16-bits, and only include the
16-bits with least significance. In other words, the field will
wrap if more than 65535 packets has been received.</t>
<t hangText="ECT (0) Counter:">The total number of RTP packets
from this SSRC the receiver has received since the receiver joined
the RTP session that had an ECN field value of ECT (0). The
receiver should keep track of this value using a local
representation that is longer than 16-bits, and only include the
16-bits with least significance. In other words, the field will
wrap if more than 65535 packets has been received.</t>
<t hangText="ECT (1) Counter:">The total number of RTP packets
from this SSRC the receiver has received since the receiver joined
the RTP session that had an ECN field value of ECT (1). The
receiver should keep track of this value using a local
representation that is longer than 16-bits, and only include the
16-bits with least significance. In other words, the field will
wrap if more than 65535 packets has been received.</t>
</list></t>
<t>The Extended Highest Sequence number and the packet loss counter
for each SSRC is not present in RTCP XR report, in contrast to the
feedback version. The reason is that this summary report will always
be sent in a RTCP compound packet where the Extended Highest Sequence
number and the accumulated number of packet losses are present in the
RTCP Sender Report or Receiver Report packet's report block.</t>
</section>
<section anchor="sec-rtcp-xr-ce"
title="RTCP XR Report Block for ECN Nonce">
<t>This RTCP XR block is for ECN Nonce reporting. It consists of an
initial part that contains the ECN nonce XOR sum followed by an Run
length encoded (RLE) bitvector that indicate which RTP sequence
numbers that wasn't included in the ECN nonce sum due to having been
lost or ECN CE marked. The bit-vector uses 1 to indicate that the
packet wasn't included in the ECN nonce sum and 0 for packets that
where.</t>
<t>The bit-vector is expressed using either Run-Length Encoding or
15-bit explicit bit-vectors. The whole vector is encoded using the
16-bit chunks as defined by Section 4.1.1, 4.1.2, and 4.1.3 in <xref
target="RFC3611"></xref>. The Terminating Null Chunk MUST be used as
padding in cases the total number of chunks would otherwise be odd and
thus the report block wouldn't reach a 32-bit boundary.</t>
<t>The ECN Nonce report block structure is the following:</t>
<t><figure>
<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 |R|R|R|R|INV|RNV| Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC of Media Sender |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Begin_seq | End_seq |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk 1 | chunk 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: ... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| chunk n-1 | chunk n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure><list style="hanging">
<t hangText="BT:">Block Type, the value identifying this block is
[TBA1].</t>
<t hangText="R:">Bits are reserved and MUST be set to 0 on
transmission and MUST be ignored on reception.</t>
<t hangText="Block Length:">The block length of this full report
block in 32-bit words minus one. The minimal report block size is
3, i.e. fixed parts (12 bytes) plus 2 chunks (4 bytes) expressed
as 32-bit words (3+1) minus 1.</t>
<t hangText="SSRC of Media Sender">SSRC of Media Sender that this
report concerns</t>
<t hangText="INV:">Initial Nonce Value. Which is the value of
Nonce prior to the XOR addition of the ECN field value for the
packet that start the nonce reporting interval. This first
included sequence number is given by the "begin_seq" value. This
to allow running calculations and only need to save nonce values
at reporting boundaries.</t>
<t hangText="RNV:">Resulting Nonce Value. The Nonce sum value
resulting after having XOR the ECN field value for all packets
received and not ECN-CE marked with the INV value up to the packet
indicated by the "end_seq" sequence number value.</t>
<t hangText="begin_seq:">First Sequence number this report
covers.</t>
<t hangText="end_seq:">Last RTP sequence number included in this
report.</t>
<t hangText="chunk i:">A chunk reporting on a part of bit-vector
indicating if the packet was excluded from the ECN Nonce due to
being lost or ECN CE marked.</t>
</list></t>
<t>The Nonce sum initial value for a new media sender (new SSRC) SHALL
be 00b. Otherwise the Initial value is the Nonce value calculated for
the RTP packet with sequence number begin_seq -1. The initial value
for the expressed reporting interval is included in the INV field. The
receiver calculate the 2-bit Nonce XOR sum over all received RTP
packets in the reporting interval including the one with end_seq
sequence number. We note that the RTCP participant doing the Nonce sum
MUST perform suppression of packet duplicates. The nonce sum will
become incorrect if any duplicates are included in the sum. All
packets not received or received as ECN-CE marked when constructing
the ECN Nonce report MUST be explicitly marked in the bitvector.</t>
<t>The Nonce reporting interval is RECOMMENDED to cover all the RTP
packets received during the three last regular reporting intervals.
This is to ensure that the sender will receive a report over all RTP
packets. Failure to deliver reports that cover all the packets may be
interpreted as an attempt to cheat. Two additional considerations must
be made when selecting the reporting interval. First, are the MTU
considerations. The packet vector and its encoding into chunks results
in a variable sized report. The size depends on two main factors, the
number of packets to report on and the frequency of bit-value changes
in the vector. The reporting interval may need to be shortened to two
or even one reporting interval if the resulting ECN nonce report
becomes too big to fit into the RTCP packet.</t>
<t>Secondly, the RTP sequence number can easily wrap and that needs to
be considered when they are handed. The report SHALL NOT report on
more than 32768 consecutive packets. The last sequence number is the
extended sequence number that is equal too or smaller (less than 65535
packets) than the value present in the Receiver Reports "extended
highest sequence number received" field. The "first sequence number"
value is thus an extended sequence number which is smaller than the
"last sequence number". If there is a wrap between the first sequence
number and the last, i.e. First sequence number > Last sequence
number (seen as 16-bit unsigned integers), then the wrap needs to
included in the calculation. If an application is having these issues,
the frequency of regular RTCP reporting should be modified by ensuring
that the application chooses appropriate settings for the minimum RTCP
reporting interval parameters.</t>
<t>Both the ECN-CE and packet loss information is structured as bit
vectors where the first bit represents the RTP packet with the
sequence number equal to the First Sequence number. The bit-vector
will contain values representing all packets up to and including the
one in the "end_seq" field. The chunk mechanism used to represent the
bit-vector in an efficient way may appear longer upon reception if an
explicit bit-vector is used as the last chunk. Bit-values representing
packets with higher sequence number (modulo 16) than "end_seq" are not
valid and SHALL be ignored.</t>
<t>The produced bit-vector is encoded using chunks. The chunks are any
of the three types defined in <xref target="RFC3611"></xref>, Run
Length Chunk (Section 4.1.1 of <xref target="RFC3611"></xref>), Bit
Vector Chunk (Section 4.1.2 of <xref target="RFC3611"></xref>), or
Terminating Null Chunk (Section 4.1.3 of <xref
target="RFC3611"></xref>). Where the Terminating Null Chunk may only
appear as the last chunk, and only in cases where the number of chunks
otherwise would be odd.</t>
</section>
</section>
<section anchor="sec-rtcp-translator-mixer"
title="Processing RTCP ECN Feedback in RTP Translators and Mixers">
<t>RTP translators and mixers that support ECN feedback are required to
process, and potentially modify or generate, RTCP packets for the
translated and/or mixed streams.</t>
<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. 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 induce corresponding gaps in the outgoing RTP
sequence numbers. An RTP translator MUST also rewrite RTCP packets to
make the corresponding changes to their sequence numbers. 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>(tbd: complete this section)</t>
</section>
<section anchor="sec-rtcp-ecn-synthetic"
title="Generating RTCP ECN Feedback in Translators">
<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>(tbd: complete this section)</t>
</section>
<section 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. An ECN-aware RTP mixer must send RTCP reports and
provide ECN feedback for the RTP flows it terminates, and must
generate RTCP reports for the RTP flow it originates, and add ECT
marks to the outgoing packets. This section describes how RTCP is
processed in RTP mixers, and how that interacts with ECN feedback.</t>
<t>(tbd: complete this section)</t>
</section>
</section>
<section anchor="sec-impl" title="Implementation considerations">
<t>To allow the use of ECN with RTP over UDP, the RTP implementation
must be able to set the ECT bits in outgoing UDP datagrams, and must 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). 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="AVPF Transport Feedback Message">
<t>A new RTCP Transport feedback message needs a FMT code point
assigned. ...</t>
</section>
<section title="RTCP XR Report blocks">
<t>Two new RTCP XR report blocks needs to be assigned block type
codes. </t>
</section>
<section title="STUN attribute">
<t>A new STUN attribute in the Comprehension-optional range needs to
be assigned...</t>
</section>
<section title="ICE Option">
<t>A new ICE option "rtp+ecn" is registered in the non-existing
registry which needs to be created.</t>
</section>
</section>
<section anchor="sec-security" title="Security Considerations">
<t>The usage of ECN with RTP over UDP as specified in this document has
the following known security issues that needs 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:">For 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. 2. Ensure that the sender disable the usage of
ECN by reporting failures to receive ECN by changing the counter
fields. The Issue, can also be accomplished by injecting false RTCP
packets to the media sender. Reporting a lot of 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 of it.</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 sensitive information. If considered
sensitive the RTCP feedback shall be encrypted.</t>
<t hangText="Changing the ECN bits">An on-path attacker that see the
RTP packet flow from sender to receiver and who has the capability
to change 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 en end-point to protect itself against. Only network
infrastructure nodes can detect this illicit remarking. 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. To mitigate the risk of cheating
receivers the solution include ECN-Nonce that makes it
probabilistically unlikely that a receiver can cheat for more than a
few packets before being found out. See <xref
target="RFC3168"></xref> and <xref target="RFC3540"></xref> for more
discussion.</t>
<t hangText="Receivers misbehaving:">A receiver may prevent the
usage of ECN in an RTP session by reporting itself as non ECN
capable or simple provide invalid ECN-nonce values. Thus 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 doesn't 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. However, this is no magic bullet
and failure to react to congestion will most likely only slightly
delay a buffer under-run, in which its session also will experience
packet loss and increased delay. There are some chance that the
media senders traffic will push other traffic out of the way without
being effected to 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>
<t hangText="ECN as covert channel:">As the ECN fields two bits can
be set to two different values for ECT, it is possible to use ECN as
a covert channel with a possible bit-rate of one or two bits per
packet. For more discussion of this issue please see <xref
target="I-D.ietf-tsvwg-ecn-tunnel"></xref>.</t>
</list></t>
<t>We note that the end-point security functions needs to prevent an
external attacker from affecting the solution easily are source
authentication and integrity protection. To prevent what information
leakage there can be from the feedback 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 needs
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="RFC3851">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="I-D.ietf-sip-sips"></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>(tbd)</t>
</section>
<section title="Open Issues">
<t>As this draft is under development some known open issues exist and
are collected here. Please consider them and provide input.</t>
<t><list style="numbers">
<t>Packet duplication. Packet duplication results in uncertainties
in the ECN summary counters. At the same time suppressing duplicates
and ignoring their ECN marks may also be problematic. Consider the
case when a packet get duplicated prior to a congestion point and
one version arrives with a ECT mark, and the other with CE mark.
What to report?</t>
<t>The negotiation and directionality attribute is going to need
some consideration for multi-party sessions when readonly capability
might be sufficient to enable ECN for all incomming streams.
However, it would beneficial to know if no potential sender support
setting ECN.</t>
<t>Consider initiation optimizations that allows for multi SSRC
sender nodes to still have rapid usage of ECN.</t>
<t>Feedback suppression for ECN-CE, both for groups, and in case an
additional CE mark arrives within a RTT at the receiver.</t>
</list></t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3168;
&rfc3550;
&rfc3611;
&rfc5234;
&rfc5348;
&rfc5389;
</references>
<references title="Informative References">
&rfc3261;
&rfc3264;
&rfc3540;
&rfc3551;
&rfc3711;
&rfc3851;
&rfc4301;
&rfc4340;
&rfc4347;
&rfc4566;
&rfc4585;
&rfc4960;
&rfc5124;
&rfc5506;
&no-op;
&rtcpssm;
&ice;
&zrtp;
&ecn-tunnel;
&sips;
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 14:32:36 |