tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 6679

 Errata 
Proposed STD
Pages: 58
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: AVTCORE

Explicit Congestion Notification (ECN) for RTP over UDP

Part 1 of 3, p. 1 to 21
None       Next RFC Part

 


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                     M. Westerlund
Request for Comments: 6679                                  I. Johansson
Category: Standards Track                                       Ericsson
ISSN: 2070-1721                                               C. Perkins
                                                   University of Glasgow
                                                             P. O'Hanlon
                                                    University of Oxford
                                                             K. Carlberg
                                                                     G11
                                                             August 2012


        Explicit Congestion Notification (ECN) for RTP over UDP

Abstract

   This memo specifies how Explicit Congestion Notification (ECN) can be
   used with the Real-time Transport Protocol (RTP) running over UDP,
   using the RTP Control Protocol (RTCP) as a feedback mechanism.  It
   defines a new RTCP Extended Report (XR) block for periodic ECN
   feedback, a new RTCP transport feedback message for timely reporting
   of congestion events, and a Session Traversal Utilities for NAT
   (STUN) extension used in the optional initialisation method using
   Interactive Connectivity Establishment (ICE).  Signalling and
   procedures for negotiation of capabilities and initialisation methods
   are also defined.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6679.

Page 2 
Copyright Notice

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Top       Page 3 
Table of Contents

   1. Introduction ....................................................4
   2. Conventions, Definitions, and Acronyms ..........................5
   3. Discussion, Requirements, and Design Rationale ..................6
      3.1. Requirements ...............................................8
      3.2. Applicability ..............................................8
      3.3. Interoperability ..........................................12
   4. Overview of Use of ECN with RTP/UDP/IP .........................13
   5. RTCP Extensions for ECN Feedback ...............................16
      5.1. RTP/AVPF Transport-Layer ECN Feedback Packet ..............16
      5.2. RTCP XR Report Block for ECN Summary Information ..........19
   6. SDP Signalling Extensions for ECN ..............................21
      6.1. Signalling ECN Capability Using SDP .......................21
      6.2. RTCP ECN Feedback SDP Parameter ...........................26
      6.3. XR Block ECN SDP Parameter ................................26
      6.4. ICE Parameter to Signal ECN Capability ....................27
   7. Use of ECN with RTP/UDP/IP .....................................27
      7.1. Negotiation of ECN Capability .............................27
      7.2. Initiation of ECN Use in an RTP Session ...................28
      7.3. Ongoing Use of ECN within an RTP Session ..................35
      7.4. Detecting Failures ........................................38
   8. Processing ECN in RTP Translators and Mixers ...................42
      8.1. Transport Translators .....................................42
      8.2. Fragmentation and Reassembly in Translators ...............43
      8.3. Generating RTCP ECN Feedback in Media Transcoders .........45
      8.4. Generating RTCP ECN Feedback in Mixers ....................46
   9. Implementation Considerations ..................................47
   10. IANA Considerations ...........................................47
      10.1. SDP Attribute Registration ...............................47
      10.2. RTP/AVPF Transport-Layer Feedback Message ................47
      10.3. RTCP Feedback SDP Parameter ..............................48
      10.4. RTCP XR Report Blocks ....................................48
      10.5. RTCP XR SDP Parameter ....................................48
      10.6. STUN Attribute ...........................................48
      10.7. ICE Option ...............................................48
   11. Security Considerations .......................................48
   12. Examples of SDP Signalling ....................................51
      12.1. Basic SDP Offer/Answer ...................................52
      12.2. Declarative Multicast SDP ................................54
   13. Acknowledgments ...............................................54
   14. References ....................................................55
      14.1. Normative References .....................................55
      14.2. Informative References ...................................56

Top      ToC       Page 4 
1.  Introduction

   This memo outlines how Explicit Congestion Notification (ECN)
   [RFC3168] can be used for Real-time Transport Protocol (RTP)
   [RFC3550] flows running over UDP/IP that use the RTP Control Protocol
   (RTCP) as a feedback mechanism.  The solution consists of feedback of
   ECN congestion experienced markings to the sender using RTCP,
   verification of ECN functionality end-to-end, and procedures for how
   to initiate ECN usage.  Since the initiation process has some
   dependencies on the signalling mechanism used to establish the RTP
   session, a specification for signalling mechanisms using the Session
   Description Protocol (SDP) [RFC4566] is included.

   ECN can be used to minimise the impact of congestion on real-time
   multimedia traffic.  The use of ECN provides a way for the network to
   send congestion control signals to the media transport without having
   to impair the media.  Unlike packet loss, ECN signals unambiguously
   indicate congestion to the transport as quickly as feedback delays
   allow and without confusing congestion with losses that might have
   occurred for other reasons such as transmission errors, packet-size
   errors, routing errors, badly implemented middleboxes, policy
   violations, and so forth.

   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 [RFC3168].  In addition,
   transport protocols have to be modified to inform the sender that
   ECN-marked packets are being received, so it can respond to the
   congestion.  The Transmission Control Protocol (TCP) [RFC3168],
   Stream Control Transmission Protocol (SCTP) [RFC4960], and Datagram
   Congestion Control Protocol (DCCP) [RFC4340] have been updated to
   support ECN, but to date, there is no specification describing how
   UDP-based transports, such as RTP [RFC3550], can use ECN.  This is
   due to the lack of feedback mechanisms in UDP.  Instead, the
   signalling control protocol on top of UDP needs to provide that
   feedback.  For RTP, that feedback is provided by RTCP.

   The remainder of this memo is structured as follows.  We start by
   describing the conventions, definitions, and acronyms used in this
   memo in Section 2 and the design rationale and applicability in
   Section 3.  Section 4 gives an overview of how ECN is used with RTP
   over UDP.  RTCP extensions for ECN feedback are defined in Section 5
   and SDP signalling extensions in Section 6.  The details of how ECN
   is used with RTP over UDP are defined in Section 7.  In Section 8, we
   describe how ECN is handled in RTP translators and mixers.  Section 9
   discusses some implementation considerations; Section 10 lists IANA
   considerations; and Section 11 discusses security considerations.

Top      ToC       Page 5 
   Finally, Section 12 provides some examples of SDP signalling for ECN
   feedback

2.  Conventions, Definitions, and Acronyms

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

   Definitions and Abbreviations:

   Sender:  A sender of RTP packets carrying an encoded media stream.
      The sender can change how the media transmission is performed by
      varying the media coding or packetisation.  It is one endpoint of
      the ECN control loop.

   Receiver:  A receiver of RTP packets with the intention to consume
      the media stream.  It sends RTCP feedback on the received stream.
      It is the other endpoint of the ECN control loop.

   ECN-Capable Host:  A sender or receiver of a media stream that is
      capable of setting and/or processing ECN marks.

   ECN-Capable Transport (ECT):  A transport flow where both sender and
      receiver are ECN-capable hosts.  Packets sent by an ECN-capable
      transport will be marked as ECT(0) or ECT(1) on transmission.  See
      [RFC3168] for the definition of the ECT(0) and ECT(1) marks.

   ECN-CE:  ECN Congestion Experienced mark (see [RFC3168]).

   ECN-Capable Packets:  Packets with ECN mark set to either ECT(0),
      ECT(1), or ECN-CE.

   Not-ECT packets:  Packets that are not sent by an ECN-capable
      transport and are not ECN-CE marked.

   ECN-Capable Queue:  A queue that supports ECN-CE marking of ECN-
      capable packets to indicate congestion.

   ECN-Blocking Middlebox:  A middlebox that discards ECN-capable
      packets.

   ECN-Reverting Middlebox:  A middlebox that changes ECN-capable
      packets to not-ECT packets by removing the ECN mark.

Top      ToC       Page 6 
   Note that RTP mixers or translators that operate in such a manner
   that they terminate or split the ECN control loop will take on the
   role of receivers or senders.  This is further discussed in
   Section 3.2.

3.  Discussion, Requirements, and Design Rationale

   ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960],
   and DCCP [RFC4340] transports.  These are all unicast protocols that
   negotiate the use of ECN during the initial connection establishment
   handshake (supporting incremental deployment and checking if ECN-
   marked packets pass all middleboxes on the path).  ECN-CE marks are
   immediately echoed back to the sender by the receiving endpoint using
   an additional bit in feedback messages, and the sender then
   interprets the mark as equivalent to a packet loss for congestion
   control purposes.

   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:

   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 setup time (i.e.,
      there is no equivalent to the TCP three-way handshake in RTP).

   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 round-trip time (RTT)
      (although the RTP Audio-Visual Profile with Feedback (RTP/AVPF)
      profile [RFC4585] allows more rapid feedback in most cases).  RTCP
      is also very much oriented around counting packets, which makes
      byte-counting congestion algorithms difficult to utilise.

   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 [RFC3550], the dynamics of the
      congestion response may be quite different to that of TCP or other
      transport protocols.

   Middleboxes:  The RTP framework explicitly supports the concept of
      mixers and translators, which are middleboxes that are involved in
      media transport functions.

Top      ToC       Page 7 
   Multicast:  RTP is explicitly a group communication protocol and was
      designed from the start to support IP multicast (primarily Any-
      Source Multicast (ASM) [RFC1112], although a recent extension
      supports Source-Specific Multicast (SSM) [RFC3569] with unicast
      feedback [RFC5760]).

   Application Awareness:  When ECN support is provided within the
      transport protocol, the ability of the application to react to
      congestion is limited, since it has little visibility into the
      transport layer.  By adding support of ECN to RTP using RTCP
      feedback, the application is made aware of congestion, allowing a
      wider range of reactions in response to that congestion
      indication.

   Counting vs. Detecting Congestion:  TCP, and the protocols derived
      from it, are mainly designed to respond in the same way whether
      they experience a burst of congestion indications within one RTT
      or just a single congestion indication, whereas real-time
      applications may be concerned with the amount of congestion
      experienced and whether it is distributed smoothly or in bursts.
      When feedback of ECN was added to TCP [RFC3168], the receiver was
      designed to flip the echo congestion experienced (ECE) flag to 1
      for a whole RTT then flop it back to zero.  ECN feedback in RTCP,
      however, will need to report a count of how much congestion has
      been experienced within an RTCP reporting period, irrespective of
      round-trip times.

   These differences 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.

   ECN support is more important for RTP sessions than, for instance, is
   the case for many applications over TCP.  This is because the impact
   of packet loss in real-time audio-visual media flows is highly
   visible to users.  For TCP-based applications, however, TCP will
   retransmit lost packets, and while extra delay is incurred by having
   packets dropped rather than ECN-CE marked, the loss is repaired.
   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 queuing delays in routers,
   lowering the round-trip time and benefiting interactive applications
   of RTP, such as voice telephony.

Top      ToC       Page 8 
3.1.  Requirements

   Considering ECN, transport protocols supporting ECN, and RTP-based
   applications, one can create a set of requirements that must be
   satisfied to at least some degree if ECN is to be used by RTP over
   UDP.

   o  REQ 1: A mechanism must exist to negotiate and initiate the use of
      ECN for RTP/UDP/IP sessions so that an RTP sender will not send
      packets with ECT in the IP header unless it knows that all
      potential receivers will understand any ECN-CE indications they
      might receive.

   o  REQ 2: A mechanism must exist to feed back the reception of any
      packets that are ECN-CE marked to the packet sender.

   o  REQ 3: The provided mechanism should minimise the possibility of
      cheating (either by the sender or receiver).

   o  REQ 4: Some detection and fallback mechanism should exist to avoid
      loss of communication due to the attempted usage of ECN in case an
      intermediate node clears ECT or drops packets that are ECT marked.

   o  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).

   o  REQ 6: Negotiation of ECN should not cause media clipping at the
      start of a session.

   The following sections describe how these requirements can be met for
   RTP over UDP.

3.2.  Applicability

   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 on the network path(s) traversed.  RTP is
   used in a heterogeneous range of network environments and topologies,
   with different signalling protocols.  The mechanisms defined here
   make it possible to verify support for ECN in each of these
   environments, irrespective of the topology.

   Due to the need for each RTP sender that intends to use ECN with RTP
   to track all participants in the RTP session, the sub-sampling of the
   group membership as specified by "Sampling of the Group Membership in
   RTP" [RFC2762] MUST NOT be used.

Top      ToC       Page 9 
   The use of ECN is further dependent on a capability of the RTP media
   flow to react to congestion signalled by ECN-marked packets.
   Depending on the application, media codec, and network topology, this
   adaptation can occur in various forms and at various nodes.  As an
   example, the sender can change the media encoding, the receiver can
   change the subscription to a layered encoding, or either reaction can
   be accomplished by a transcoding middlebox.  [RFC5117] identifies
   seven topologies in which RTP sessions may be configured and which
   may affect the ability to use ECN:

   Topo-Point-to-Point:  This utilises standard unicast flows.  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.

   Topo-Multicast:  This is either an Any-Source Multicast (ASM) group
      [RFC3569] with potentially several active senders and multicast
      RTCP feedback or a Source-Specific Multicast (SSM) group [RFC4607]
      with a single distribution source and unicast RTCP feedback from
      receivers.  RTCP is designed to scale to large group sizes while
      avoiding feedback implosion (see Section 6.2 of [RFC3550],
      [RFC4585], and [RFC5760]) and can be used by a sender to determine
      if all its receivers, and the network paths to those receivers,
      support ECN (see Section 7.2).  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, irrespective of
      whether the paths from other senders to their receivers support
      ECN ("all its known receivers" are all the synchronisation sources
      (SSRCs) from which the RTP sender has received RTP or RTCP in the
      last five reporting intervals, i.e., they have not timed out).
      Note that group membership may change during the lifetime of a
      multicast RTP session, potentially introducing new receivers that
      are not ECN capable or have a path that doesn't support ECN.
      Senders must use the mechanisms described in Section 7.4 to check
      that all receivers, and the network paths traversed to reach those
      receivers, continue to support ECN, and they need to fallback to
      non-ECN use if any receivers join that do not.

      SSM groups that use unicast RTCP feedback [RFC5760] do need a few
      extra considerations.  This topology can have multiple media
      senders that provide traffic to the distribution source (DS) and
      are separated from the DS.  There can also be multiple feedback
      targets.  The requirement for using ECN for RTP in this topology
      is that the media sender must be provided the feedback from the
      receivers.  It may be in aggregated form from the feedback
      targets.  We will not mention this SSM use case in the below text

Top      ToC       Page 10 
      specifically, but when actions are required by the media source,
      they also apply to the case of SSM where the RTCP feedback goes to
      the feedback target.

      The mechanisms defined in this memo support multicast groups but
      are known to be conservative and don't scale to large groups.
      This is primarily because we require all members of the group to
      demonstrate that they can make use of ECN before the sender is
      allowed to send ECN-marked packets, since allowing some non-ECN-
      capable receivers causes fairness issues when the bottleneck link
      is shared by ECN and non-ECN flows that we have not (yet) been
      able to satisfactorily address.  The rules regarding Determination
      of ECN Support in Section 7.2.1 may be relaxed in a future version
      of this specification to improve scaling once these issues have
      been resolved.

   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 translators: those that do not modify
      the media stream and are concerned with transport parameters, for
      example, a multicast to unicast gateway; and those that do modify
      the media stream, for example, transcoding between different media
      codecs.  A single RTP session traverses the translator, and the
      translator must rewrite RTCP messages passing through it to match
      the changes it makes to the RTP data packets.  A legacy, ECN-
      unaware, RTP translator is expected to ignore the ECN bits on
      received packets and to set the ECN bits to not-ECT when sending
      packets, thus causing ECN negotiation on the path containing the
      translator to fail (any new RTP translator that does not wish to
      support ECN may do so similarly).  An ECN-aware RTP translator may
      act in one of three ways:

      *  If the translator does not modify the media stream, it should
         copy the ECN bits unchanged from the incoming to the outgoing
         datagrams, unless it is overloaded and experiencing congestion,
         in which case it may mark the outgoing datagrams with an ECN-CE
         mark.  Such a translator passes RTCP feedback unchanged.  See
         Section 8.1.

      *  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 [RFC3168].  See Section 8.2 for details.

      *  If the translator is a media transcoder, or otherwise modifies
         the content of the media stream, the output RTP media stream
         may have radically different characteristics than the input RTP

Top      ToC       Page 11 
         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 to 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 Section 8.3).

      It is recognised that ECN and RTCP processing in an RTP translator
      that modifies the media stream is non-trivial.

   Topo-Mixer:  A mixer is an RTP-level middlebox that aggregates
      multiple RTP streams, mixing them together to generate a new RTP
      stream.  The mixer is visible to the other participants in the RTP
      session and is also usually visible in the associated signalling
      session.  The RTP flows on each side of the mixer are treated
      independently for ECN purposes, with the mixer generating its own
      RTCP ECN feedback and responding to ECN feedback for data it
      sends.  Since unicast transport between the mixer and any endpoint
      are treated independently, it would seem reasonable to allow the
      transport on one side of the mixer to use ECN, while the transport
      on the other side of the mixer is not ECN capable, if this is
      desired.  See Section 8.4 for details on how mixers should process
      ECN.

   Topo-Video-switch-MCU:  A video-switching Multipoint Control Unit
      (MCU) receives several RTP flows, but forwards only one of those
      flows onwards to the other participants at a time.  The flow that
      is forwarded changes during the session, often based on voice
      activity.  Since only a subset of the RTP packets generated by a
      sender are forwarded to the receivers, a video-switching MCU can
      break ECN negotiation (the success of the ECN negotiation may
      depend on the voice activity of the participant at the instant the
      negotiation takes place - shout if you want ECN).  It also breaks
      congestion feedback and response, since RTP packets are dropped by
      the MCU depending on voice activity rather than network
      congestion.  This topology is widely used in legacy products but
      is NOT RECOMMENDED for new implementations and SHALL NOT be used
      with ECN.

   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.

Top      ToC       Page 12 
   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 [RFC5117], "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".

   These topologies may be combined within a single RTP session.

   The ECN mechanism defined in this memo is applicable to both sender-
   and receiver-controlled congestion algorithms.  The mechanism ensures
   that both senders and receivers will know about ECN-CE markings and
   any packet losses.  Thus, the actual decision point for the
   congestion control is not relevant.  This is a great benefit as the
   rate of an RTP session can be varied in a number of ways, for
   example, a unicast media sender might use TCP Friendly Rate Control
   (TFRC) [RFC5348] or some other algorithm, while a multicast session
   could use a sender-based scheme adapting to the lowest common
   supported rate or a receiver-driven mechanism using layered coding to
   support more heterogeneous paths.

   To ensure timely feedback of ECN-CE-marked packets when needed, this
   mechanism requires support for the RTP/AVPF profile [RFC4585] or any
   of its derivatives, such as RTP/SAVPF [RFC5124].  The standard RTP/
   AVP profile [RFC3551] does not allow any early or immediate
   transmission of RTCP feedback and has a minimal RTCP interval whose
   default value (5 seconds) is many times the normal RTT between sender
   and receiver.

3.3.  Interoperability

   To ensure interoperability for this specification, there is need for
   at least one common initialisation method for all implementations.
   Since initialisation using RTP and RTCP (Section 7.2.1) is the one
   method that works in all cases, although it is not optimal for all
   uses, it is selected as the mandatory-to-implement initialisation
   method.  This method requires both the RTCP XR extension and the ECN
   feedback format, which require the RTP/AVPF profile to ensure timely
   feedback.

   When one considers all the uses of ECN for RTP, it is clear that
   congestion control mechanisms exist that are receiver driven only
   (Section 7.3.3).  These congestion control mechanisms do not require
   timely feedback of congestion events to the sender.  If such a
   congestion control mechanism is combined with an initialisation
   method that also doesn't require timely feedback using RTCP, like the
   leap-of-faith method (Section 7.2.3) or the ICE-based method
   (Section 7.2.2), then neither the ECN feedback format nor the RTP/
   AVPF profile would appear to be needed.  However, fault detection can

Top      ToC       Page 13 
   be greatly improved by using receiver-side detection (Section 7.4.1)
   and early reporting of such cases using the ECN feedback mechanism.

   For interoperability, we mandate the implementation of the RTP/AVPF
   profile, with both RTCP extensions and the necessary signalling to
   support a common operations mode.  This specification recommends the
   use of RTP/AVPF in all cases as negotiation of the common
   interoperability point requires RTP/AVPF, mixed negotiation of RTP/
   AVP and RTP/AVPF depending on other SDP attributes in the same media
   block is difficult, and the fact that fault detection can be improved
   when using RTP/AVPF.

   The use of the ECN feedback format is also recommended, but cases
   exist where its use is not required because timely feedback is not
   needed.  These will be explicitly noted using the phrase "no timely
   feedback required" and generally occur in combination with receiver-
   driven congestion control and with the leap-of-faith and ICE-based
   initialisation methods.  We also note that any receiver-driven
   congestion control solution that still requires RTCP for signalling
   of any adaptation information to the sender will still require RTP/
   AVPF for timeliness.

4.  Overview of Use of ECN with RTP/UDP/IP

   The solution for using ECN with RTP over UDP/IP consists of four
   different pieces that together make the solution work:

   1.  Negotiation of the capability to use ECN with RTP/UDP/IP

   2.  Initiation and initial verification of ECN-capable transport

   3.  Ongoing use of ECN within an RTP session

   4.  Handling of dynamic behaviour through failure detection,
       verification, and fallback

   Before an RTP session can be created, a signalling protocol is used
   to negotiate or at least configure session parameters (see
   Section 7.1).  In some topologies, the signalling protocol can also
   be used to discover the other participants.  One of the parameters
   that must be agreed is the capability of a participant to support
   ECN.  Note that all participants having the capability of supporting
   ECN does not necessarily imply that ECN is usable in an RTP session,
   since there may be middleboxes on the path between the participants
   that don't pass ECN-marked packets (for example, a firewall that
   blocks traffic with the ECN bits set).  This document defines the
   information that needs to be negotiated and provides a mapping to SDP
   for use in both declarative and offer/answer contexts.

Top      ToC       Page 14 
   When a sender joins a session for which all participants claim to
   support ECN, it needs to verify that the ECN support is usable.
   There are three ways in which this verification can be done:

   o  The sender may generate a (small) subset of its RTP data packets
      with the ECN field of the IP header set to ECT(0) or ECT(1).  Each
      receiver will then send an RTCP feedback packet indicating the
      reception of the ECT-marked RTP packets.  Upon reception of this
      feedback from each receiver it knows of, the sender can consider
      ECN functional for its traffic.  Each sender does this
      verification independently.  When a new receiver joins an existing
      RTP session, it will send RTCP reports in the usual manner.  If
      those RTCP reports include ECN information, verification will have
      succeeded, and sources can continue to send ECT packets.  If not,
      verification fails, and each sender MUST stop using ECN (see
      Section 7.2.1 for details).

   o  Alternatively, ECN support can be verified during an initial end-
      to-end STUN exchange (for example, as part of ICE connection
      establishment).  After having verified connectivity without ECN
      capability, an extra STUN exchange, this time with the ECN field
      set to ECT(0) or ECT(1), is performed on the candidate path that
      is about to be used.  If successful, the path's capability to
      convey ECN-marked packets is verified.  A new STUN attribute is
      defined to convey feedback that the ECT-marked STUN request was
      received (see Section 7.2.2), along with an ICE signalling option
      (Section 6.4) to indicate that the check is to be performed.

   o  Thirdly, the sender may make a leap of faith that ECN will work.
      This is only recommended for applications that know they are
      running in controlled environments where ECN functionality has
      been verified through other means.  In this mode, it is assumed
      that ECN works, and the system reacts to failure indicators if the
      assumption proved wrong.  The use of this method relies on a high
      confidence that ECN operation will be successful or an application
      where failure is not serious.  The impact on the network and other
      users must be considered when making a leap of faith, so there are
      limitations on when this method is allowed (see Section 7.2.3).

   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

Top      ToC       Page 15 
   not pass ECN, the impact on the application can be severe: in the
   worst case, all media could be lost if a middlebox that discards ECN-
   marked packets is present.  A less severe effect, but still requiring
   reaction, is the presence of a middlebox that re-marks ECT-marked
   packets to not-ECT, possibly marking packets with an ECN-CE mark as
   not-ECT.  This could result in increased levels of congestion due to
   non-responsiveness and impact media quality as applications end up
   relying on packet loss as an indication of congestion.

   Once ECN support has been verified (or assumed) to work for all
   receivers, a sender marks all its RTP packets as ECT packets, while
   receivers rapidly feed back reports on any ECN-CE marks to the sender
   using RTCP in RTP/AVPF immediate or early feedback mode, unless no
   timely feedback is required.  Each feedback report indicates the
   receipt of new ECN-CE marks since the last ECN feedback packet and
   also counts the total number of ECN-CE-marked packets as a cumulative
   sum.  This is the mechanism to provide the fastest possible feedback
   to senders about ECN-CE marks.  On receipt of an ECN-CE-marked
   packet, the system must react to congestion as if packet loss has
   been reported.  Section 7.3 describes the ongoing use of ECN within
   an RTP session.

   This rapid feedback is not optimised for reliability, so another
   mechanism, RTCP XR ECN Summary Reports, is used to ensure more
   reliable, but less timely, reporting of the ECN information.  The ECN
   Summary Report contains the same information as the ECN feedback
   format, only packed differently for better efficiency with reports
   for many sources.  It is sent in a compound RTCP packet, along with
   regular RTCP reception reports.  By using cumulative counters for
   observed ECN-CE, ECT, not-ECT, packet duplication, and packet loss,
   the sender can determine what events have happened since the last
   report, independently of any RTCP packets having been lost.

   RTCP reports MUST NOT be ECT marked, since ECT-marked traffic may be
   dropped if the path is not ECN compliant.  RTCP is used to provide
   feedback about what has been transmitted and what ECN markings that
   are received, so it is important that it is received in cases when
   ECT-marked traffic is not getting through.

   There are numerous reasons why the path the RTP packets take from the
   sender to the receiver may change, e.g., mobility and link failure
   followed by re-routing around it.  Such an event may result in the
   packet being sent through a node that is ECN non-compliant, thus
   re-marking or dropping packets with ECT set.  To prevent this from
   impacting the application for longer than necessary, the operation of
   ECN is constantly monitored by all senders (Section 7.4).  Both the
   RTCP XR ECN Summary Reports and the ECN feedback packets allow the
   sender to compare the number of ECT(0), ECT(1), and not-ECT-marked

Top      ToC       Page 16 
   packets received with the number that were sent, while also reporting
   ECN-CE-marked and lost packets.  If these numbers do not agree, it
   can be inferred that the path does not reliably pass ECN-marked
   packets.  A sender detecting a possible ECN non-compliance issue
   should then stop sending ECT-marked packets to determine if that
   allows the packets to be correctly delivered.  If the issues can be
   connected to ECN, then ECN usage is suspended.

5.  RTCP Extensions for ECN Feedback

   This memo defines two new RTCP extensions: one RTP/AVPF [RFC4585]
   transport-layer feedback format for reporting urgent ECN information
   and one RTCP XR [RFC3611] ECN Summary Report block type for regular
   reporting of the ECN marking information.

5.1.  RTP/AVPF Transport-Layer ECN Feedback Packet

   This RTP/AVPF transport-layer feedback format is intended for use in
   RTP/AVPF early or immediate feedback modes when information needs to
   urgently reach the sender.  Thus, its main use is to report reception
   of an ECN-CE-marked RTP packet so that the sender may perform
   congestion control or to speed up the initiation procedures by
   rapidly reporting that the path can support ECN-marked traffic.  The
   feedback format is also defined with reduced-size RTCP [RFC5506] in
   mind, where RTCP feedback packets may be sent without accompanying
   Sender or Receiver Reports that would contain the extended highest
   sequence number and the accumulated number of packet losses.  Both
   are important for ECN to verify functionality and keep track of when
   CE marking does occur.

   The RTP/AVPF transport-layer feedback packet starts with the common
   header defined by the RTP/AVPF profile [RFC4585], which is reproduced
   in Figure 1.  The FMT field takes the value 8 to indicate that the
   Feedback Control Information (FCI) contains an ECN Feedback Report,
   as defined in Figure 2.

Top      ToC       Page 17 
    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=8  |  PT=RTPFB=205 |          length               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of packet sender                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  SSRC of media source                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   :            Feedback Control Information (FCI)                 :
   :                                                               :

       Figure 1: RTP/AVPF Common Packet Format for Feedback Messages


    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Extended Highest Sequence Number                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ECT (0) Counter                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ECT (1) Counter                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ECN-CE Counter                | not-ECT Counter               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Lost Packets Counter          | Duplication Counter           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 2: ECN Feedback Report Format

   The ECN Feedback Report contains the following fields:

   Extended Highest Sequence Number:  The 32-bit extended highest
      sequence number received, as defined by [RFC3550].  Indicates the
      highest RTP sequence number to which this report relates.

   ECT(0) Counter:  The 32-bit cumulative number of RTP packets with
      ECT(0) received from this SSRC.

   ECT(1) Counter:  The 32-bit cumulative number of RTP packets with
      ECT(1) received from this SSRC.

   ECN-CE Counter:  The cumulative number of RTP packets received from
      this SSRC since the receiver joined the RTP session that were
      ECN-CE marked, including ECN-CE marks in any duplicate packets.
      The receiver should keep track of this value using a local
      representation that is at least 32 bits and only include the 16

Top      ToC       Page 18 
      bits with least significance.  In other words, the field will wrap
      if more than 65535 ECN-CE-marked packets have been received.

   not-ECT Counter:  The cumulative number of RTP packets received from
      this SSRC since the receiver joined the RTP session that had an
      ECN field value of not-ECT.  The receiver should keep track of
      this value using a local representation that is at least 32 bits
      and only include the 16 bits with least significance.  In other
      words, the field will wrap if more than 65535 not-ECT packets have
      been received.

   Lost Packets Counter:  The cumulative number of RTP packets that the
      receiver expected to receive minus the number of packets it
      actually received that are not a duplicate of an already received
      packet, from this SSRC since the receiver joined the RTP session.
      Note that packets that arrive late are not counted as lost.  The
      receiver should keep track of this value using a local
      representation that is at least 32 bits and only include the 16
      bits with least significance.  In other words, the field will wrap
      if more than 65535 packets are lost.

   Duplication Counter:  The cumulative number of RTP packets received
      that are a duplicate of an already received packet from this SSRC
      since the receiver joined the RTP session.  The receiver should
      keep track of this value using a local representation that is at
      least 32 bits and only include the 16 bits with least
      significance.  In other words, the field will wrap if more than
      65535 duplicate packets have been received.

   All fields in the ECN Feedback Report are unsigned integers in
   network byte order.  Each ECN Feedback Report corresponds to a single
   RTP source (SSRC).  Multiple sources can be reported by including
   multiple ECN Feedback Report packets in an compound RTCP packet.

   The counters SHALL be initiated to 0 for each new SSRC received.
   This enables detection of ECN-CE marks or packet loss on the initial
   report from a specific participant.

   The use of at least 32-bit counters allows even extremely high packet
   volume applications to not have wrapping of counters within any
   timescale close to the RTCP reporting intervals.  However, 32 bits
   are not sufficiently large to disregard the fact that wrappings may
   happen during the lifetime of a long-lived RTP session, and
   implementations need to be written to handle wrapping of the
   counters.  It is recommended that implementations use local
   representation of these counters that are longer than 32 bits to
   enable easy handling of wraps.

Top      ToC       Page 19 
   There is a difference in packet duplication reports between the
   packet loss counter that is defined in the Receiver Report Block
   [RFC3550] and that defined here.  To avoid holding state for what RTP
   sequence numbers have been received, [RFC3550] specifies that one can
   count packet loss by counting the number of received packets and
   comparing that to the number of packets expected.  As a result, a
   packet duplication can hide a packet loss.  However, when populating
   the ECN Feedback Report, a receiver needs to track the sequence
   numbers actually received and count duplicates and packet loss
   separately to provide a more reliable indication.  Reordering may,
   however, still result in packet loss being reported in one report and
   then removed in the next.

   The ECN-CE counter is robust for packet duplication.  Adding each
   received ECN-CE-marked packet to the counter is not an issue; in
   fact, it is required to ensure complete tracking of the ECN state.
   If one of the clones was ECN-CE marked, that is still an indication
   of congestion.  Packet duplication has a potential impact on the ECN
   verification, and there is thus a need to count the duplicates.

5.2.  RTCP XR Report Block for ECN Summary Information

   This unilateral XR report block combined with RTCP SR or RR report
   blocks carries the same information as the ECN Feedback Report and is
   based on the same underlying information.  However, the ECN Feedback
   Report is intended to report an ECN-CE mark as soon as possible,
   while this extended report is for the regular RTCP reporting and
   continuous verification of the ECN functionality end-to-end.

   The ECN Summary Report block consists of one RTCP XR report block
   header, shown in Figure 3 followed by one or more ECN Summary Report
   data blocks, as defined in Figure 4.

    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=13     | Reserved      |         Block Length          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 3: RTCP XR Report Header

Top      ToC       Page 20 
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | SSRC of Media Sender                                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ECT (0) Counter                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ECT (1) Counter                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ECN-CE Counter                | not-ECT Counter               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Lost Packets Counter          | Duplication Counter           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 4: RTCP XR ECN Summary Report

   The RTCP XR ECN Summary Report contains the following fields:

   BT:  Block Type identifying the ECN Summary Report block.  Value is
      13.

   Reserved:  All bits SHALL be set to 0 on transmission and ignored on
      reception.

   Block Length:  The length of this XR report block, including the
      header, in 32-bit words minus one.  Used to indicate the number of
      ECN Summary Report data blocks present in the ECN Summary Report.
      This length will be 5*n, where n is the number of ECN Summary
      Report blocks, since blocks are a fixed size.  The block length
      MAY be zero if there is nothing to report.  Receivers MUST discard
      reports where the block length is not a multiple of five, since
      these cannot be valid.

   SSRC of Media Sender:  The SSRC identifying the media sender this
      report is for.

   ECT(0) Counter:  as in Section 5.1.

   ECT(1) Counter:  as in Section 5.1.

   ECN-CE Counter:  as in Section 5.1.

   not-ECT Counter:  as in Section 5.1.

   Lost Packets Counter:  as in Section 5.1.

   Duplication Counter:  as in Section 5.1.

Top      ToC       Page 21 
   The extended highest sequence number counter for each SSRC is not
   present in an RTCP XR report, in contrast to the feedback version.
   The reason is that this summary report will rely on the information
   sent in the Sender Report (SR) or Receiver Report (RR) blocks part of
   the same RTCP compound packet.  The extended highest sequence number
   is available from the SR or RR.

   All the SSRCs that are present in the SR or RR SHOULD also be
   included in the RTCP XR ECN Summary Report.  In cases where the
   number of senders are so large that the combination of SR/RR and the
   ECN summary for all the senders exceed the MTU, then only a subset of
   the senders SHOULD be included so that the reports for the subset
   fits within the MTU.  The subsets SHOULD be selected round-robin
   across multiple intervals so that all sources are periodically
   reported.  In case there are no SSRCs that currently are counted as
   senders in the session, the report block SHALL still be sent with no
   report block entry and a zero report block length to continuously
   indicate to the other participants the receiver capability to report
   ECN information.



(page 21 continued on part 2)

Next RFC Part