Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 6679

Explicit Congestion Notification (ECN) for RTP over UDP

Pages: 58
Proposed Standard
Errata
Updated by:  8311
Part 2 of 3 – Pages 21 to 42
First   Prev   Next

Top   ToC   RFC6679 - Page 21   prevText

6. SDP Signalling Extensions for ECN

This section defines a number of SDP signalling extensions used in the negotiation of the ECN for RTP support when using SDP. This includes one SDP attribute "a=ecn-capable-rtp:" that negotiates the actual operation of ECN for RTP. Two SDP signalling parameters are defined to indicate the use of the RTCP XR ECN summary block and the RTP/AVPF feedback format for ECN. One ICE option SDP representation is also defined.

6.1. Signalling ECN Capability Using SDP

One new SDP attribute, "a=ecn-capable-rtp:", is defined. This is a media-level attribute and MUST NOT be used at the session level. It is not subject to the character set chosen. The aim of this signalling is to indicate the capability of the sender and receivers to support ECN, and to negotiate the method of ECN initiation to be used in the session. The attribute takes a list of initiation methods, ordered in decreasing preference. The defined values for the initiation method are: rtp: Using RTP and RTCP as defined in Section 7.2.1. ice: Using STUN within ICE as defined in Section 7.2.2. leap: Using the leap-of-faith method as defined in Section 7.2.3.
Top   ToC   RFC6679 - Page 22
   Further methods may be specified in the future, so unknown methods
   MUST be ignored upon reception.

   In addition, a number of OPTIONAL parameters may be included in the
   "a=ecn-capable-rtp:" attribute as follows:

   mode:  This parameter signals the endpoint's capability to set and
      read ECN marks in UDP packets.  An examination of various
      operating systems has shown that end-system support for ECN
      marking of UDP packets may be symmetric or asymmetric.  By this,
      we mean that some systems may allow endpoints to set the ECN bits
      in an outgoing UDP packet but not read them, while others may
      allow applications to read the ECN bits but not set them.  This
      either/or case may produce an asymmetric support for ECN and thus
      should be conveyed in the SDP signalling.  The "mode=setread"
      state is the ideal condition where an endpoint can both set and
      read ECN bits in UDP packets.  The "mode=setonly" state indicates
      that an endpoint can set the ECT bit but cannot read the ECN bits
      from received UDP packets to determine if upstream congestion
      occurred.  The "mode=readonly" state indicates that the endpoint
      can read the ECN bits to determine if congestion has occurred for
      incoming packets, but it cannot set the ECT bits in outgoing UDP
      packets.  When the "mode=" parameter is omitted, it is assumed
      that the node has "setread" capabilities.  This option can provide
      for an early indication that ECN cannot be used in a session.
      This would be the case when both the offerer and answerer set the
      "mode=" parameter to "setonly" or both set it to "readonly".

   ect:  This parameter makes it possible to express the preferred ECT
      marking.  This is either "random", "0", or "1", with "0" being
      implied if not specified.  The "ect" parameter describes a
      receiver preference and is useful in the case where the receiver
      knows it is behind a link using IP header compression, the
      efficiency of which would be seriously disrupted if it were to
      receive packets with randomly chosen ECT marks.  It is RECOMMENDED
      that ECT(0) marking be used.
Top   ToC   RFC6679 - Page 23
   The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp:" attribute is
   shown in Figure 5.

      ecn-attribute  = "a=ecn-capable-rtp:" SP init-list [SP parm-list]
      init-list      = init-value *("," init-value)
      init-value     = "rtp" / "ice" / "leap" / init-ext
      init-ext       = token
      parm-list      = parm-value *(";" SP parm-value)
      parm-value     = mode / ect / parm-ext
      mode           = "mode=" ("setonly" / "setread" / "readonly")
      ect            = "ect=" ("0" / "1" / "random")
      parm-ext       = parm-name "=" parm-value-ext
      parm-name      = token
      parm-value-ext = token / quoted-string
      quoted-string = ( DQUOTE *qdtext DQUOTE )
      qdtext = %x20-21 / %x23-5B / %x5D-7E / quoted-pair / UTF8-NONASCII
         ; No DQUOTE and no "\"
      quoted-pair = "\\" / ( "\" DQUOTE )
      UTF8-NONASCII = UTF8-1 / UTF8-2 / UTF8-3 / UTF8-4

      ; external references:
        ; token from RFC 4566
        ; SP and DQUOTE from RFC 5234
        ; UTF8-1, UTF8-2, UTF8-3, and UTF8-4 from RFC 3629

       Figure 5: ABNF Grammar for the "a=ecn-capable-rtp:" Attribute

   Note the above quoted string construct has an escaping mechanism for
   strings containing ".  This uses \ (backslash) as an escaping
   mechanism, i.e., a " is replaced by \" (backslash double quote) and
   any \ (backslash) is replaced by \\ (backslash backslash) when put
   into the double quotes as defined by the above syntax.  The string in
   a quoted string is UTF-8 [RFC3629].

6.1.1. Use of "a=ecn-capable-rtp:" with the Offer/Answer Model

When SDP is used with the offer/answer model [RFC3264], the party generating the SDP offer MUST insert an "a=ecn-capable-rtp:" attribute into the media section of the SDP offer of each RTP session for which it wishes to use ECN. The attribute includes one or more ECN initiation methods in a comma-separated list in decreasing order of preference, with any number of optional parameters following. The answering party compares the list of initiation methods in the offer with those it supports in order of preference. If there is a match and if the receiver wishes to attempt to use ECN in the session, it includes an "a=ecn-capable-rtp:" attribute containing its single preferred choice of initiation method, and any optional parameters, in the media sections of the answer. If there is no matching
Top   ToC   RFC6679 - Page 24
   initiation method capability, or if the receiver does not wish to
   attempt to use ECN in the session, it does not include an "a=ecn--
   capable-rtp:" attribute in its answer.  If the attribute is removed
   in the answer, then ECN MUST NOT be used in any direction for that
   media flow.  If there are initialisation methods that are unknown,
   they MUST be ignored on reception and MUST NOT be included in an
   answer.

   The endpoints' capability to set and read ECN marks, as expressed by
   the optional "mode=" parameter, determines whether ECN support can be
   negotiated for flows in one or both directions:

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

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

   o  If the "mode=setread" parameter is present in the "a=ecn-capable-
      rtp:" attribute of the offer and the answering party is "setonly",
      then ECN may only be initiated in the direction from the answering
      party to the offering party.  If the offering party is
      "mode=setread" but the answering party is "mode=readonly", then
      ECN may only be initiated in the direction from the offering party
      to the answering party.  If both offer and answer are
      "mode=setread", then ECN may be initiated in both directions.
      Note that "mode=setread" is implied by the absence of a "mode="
      parameter in the offer or the answer.

   o  An offer that does not include a "mode=" parameter MUST be treated
      as if a "mode=setread" parameter had been included.

   In an RTP session using multicast and ECN, participants that intend
   to send RTP packets SHOULD support setting ECT marks in RTP packets
   (i.e., should be "mode=setonly" or "mode=setread").  Participants
   receiving data need the capability to read ECN marks on incoming
   packets.  It is important that receivers can read ECN marks
   ("mode=readonly" or "mode=setread"), since otherwise no sender in the
Top   ToC   RFC6679 - Page 25
   multicast session would be able to enable ECN.  Accordingly,
   receivers that are "mode=setonly" SHOULD NOT join multicast RTP
   sessions that use ECN.  If session participants that are not aware of
   the ECN for RTP signalling are invited to a multicast session and
   simply ignore the signalling attribute, the other party in the offer/
   answer exchange SHOULD terminate the SDP dialogue so that the
   participant leaves the session.

   The "ect=" parameter in the "a=ecn-capable-rtp:" attribute is set
   independently in the offer and the answer.  Its value in the offer
   indicates a preference for the sending behaviour of the answering
   party, and its value in the answer indicates a sending preference for
   the behaviour of the offering party.  It will be the sender's choice
   to honour the receiver's preference for what to receive or not.  In
   multicast sessions, all senders SHOULD set the ECT marks using the
   value declared in the "ect=" parameter.

   Unknown optional parameters MUST be ignored on reception and MUST NOT
   be included in the answer.  That way, a new parameter may be
   introduced and verified as supported by the other endpoint by having
   the endpoint include it in any answer.

6.1.2. Use of "a=ecn-capable-rtp:" with Declarative SDP

When SDP is used in a declarative manner, for example, in a multicast session using the Session Announcement Protocol (SAP) [RFC2974], negotiation of session description parameters is not possible. The "a=ecn-capable-rtp:" attribute MAY be added to the session description to indicate that the sender will use ECN in the RTP session. The attribute MUST include a single method of initiation. Participants MUST NOT join such a session unless they have the capability to receive ECN-marked UDP packets, implement the method of initiation, and generate RTCP ECN feedback. The mode parameter MAY also be included in declarative usage, to indicate the minimal capability is required by the consumer of the SDP. So, for example, in an SSM session, the participants configured with a particular SDP will all be in a media receive-only mode; thus, "mode=readonly" may be used as the receiver only needs to be able to report on the ECN markings. In ASM sessions, using "mode=readonly" is also reasonable, unless all senders are required to attempt to use ECN for their outgoing RTP data traffic, in which case the mode needs to be set to "setread".

6.1.3. General Use of the "a=ecn-capable-rtp:" Attribute

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.
Top   ToC   RFC6679 - Page 26
   As described in Section 7.3.3, RTP sessions using ECN require rapid
   RTCP ECN feedback, unless timely feedback is not required due to a
   receiver-driven congestion control.  To ensure that the sender can
   react to ECN-CE-marked packets, timely feedback is usually required.
   Thus, the use of the Extended RTP Profile for RTCP-Based Feedback
   (RTP/AVPF) [RFC4585] or another profile that inherits RTP/AVPF's
   signalling rules MUST be signalled unless timely feedback is not
   required.  If timely feedback is not required, it is still
   RECOMMENDED to use RTP/AVPF.  The signalling of an RTP/AVPF-based
   profile is likely to be required even if the preferred method of
   initialisation and the congestion control do not require timely
   feedback, as the common interoperable method is likely to be
   signalled or the improved fault reaction is desired.

6.2. RTCP ECN Feedback SDP Parameter

A new "nack" feedback parameter "ecn" is defined to indicate the usage of the RTCP ECN feedback packet format (Section 5.1). The ABNF [RFC5234] definition of the SDP parameter extension is: rtcp-fb-nack-param = <See Section 4.2 of [RFC4585]> rtcp-fb-nack-param =/ ecn-fb-par ecn-fb-par = SP "ecn" The offer/answer rules for these SDP feedback parameters are specified in the RTP/AVPF profile [RFC4585].

6.3. XR Block ECN SDP Parameter

A new unilateral RTCP XR block for ECN summary information is specified; thus, the XR block SDP signalling also needs to be extended with a parameter. This is done in the same way as for the other XR blocks. The XR block SDP attribute as defined in Section 5.1 of the RTCP XR specification [RFC3611] is defined to be extensible. As no parameter values are needed for this ECN summary block, this parameter extension consists of a simple parameter name used to indicate support and intent to use the XR block. xr-format = <See Section 5.1 of [RFC3611]> xr-format =/ ecn-summary-par ecn-summary-par = "ecn-sum" For SDP declarative and offer/answer usage, see the RTCP XR specification [RFC3611] and its description of how to handle unilateral parameters.
Top   ToC   RFC6679 - Page 27

6.4. ICE Parameter to Signal ECN Capability

One new ICE [RFC5245] option, "rtp+ecn", is defined. This is used with the SDP session level "a=ice-options" attribute in an SDP offer to indicate that the initiator of the ICE exchange has the capability to support ECN for RTP-over-UDP flows (via "a=ice-options: rtp+ecn"). The answering party includes this same attribute at the session level in the SDP answer if it also has the capability and removes the attribute if it does not wish to use ECN or doesn't have the capability to use ECN. If the ICE initiation method (Section 7.2.2) is actually going to be used, it is also needs to be explicitly negotiated using the "a=ecn-capable-rtp:" attribute. This ICE option SHALL be included when the ICE initiation method is offered or declared in the SDP. 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.

7. Use of ECN with RTP/UDP/IP

In the detailed specification of the behaviour below, the different functions in the general case will first be discussed. In case special considerations are needed for middleboxes, multicast usage, etc., those will be specially discussed in related subsections.

7.1. Negotiation of ECN Capability

The first stage of ECN negotiation for RTP over UDP is to signal the capability to use ECN. An RTP system that supports ECN and uses SDP for its signalling MUST implement the SDP extension to signal ECN capability as described in Section 6.1, the RTCP ECN feedback SDP parameter defined in Section 6.2, and the XR Block ECN SDP parameter defined in Section 6.3. It MAY also implement alternative ECN capability negotiation schemes, such as the ICE extension described in Section 6.4. Other signalling systems will need to define signalling parameters corresponding to those defined for SDP. The "ecn-capable-rtp:" SDP attribute MUST be used when employing ECN for RTP according to this specification in systems using SDP. As the RTCP XR ECN Summary Report is required independently of the initialisation method or congestion control scheme, the "rtcp-xr" attribute with the "ecn-sum" parameter MUST also be used. The "rtcp-fb" attribute with the "nack" parameter "ecn" MUST be used whenever the initialisation method or a congestion control algorithm
Top   ToC   RFC6679 - Page 28
   requires timely sender-side knowledge of received CE markings.  If
   the congestion control scheme requires additional signalling, this
   should be indicated as appropriate.

7.2. Initiation of ECN Use in an RTP Session

Once the sender and the receiver(s) have agreed that they have the capability to use ECN within a session, they may attempt to initiate ECN use. All session participants connected over the same transport MUST use the same initiation method. RTP mixers or translators can use different initiation methods to different participants that are connected over different underlying transports. The mixer or translator will need to do individual signalling with each participant to ensure it is consistent with the ECN support in those cases where it does not function as one endpoint for the ECN control loop. At the start of the RTP session, when the first few packets with ECT are sent, it is important to verify that IP packets with ECN field values of ECT or ECN-CE will reach their destination(s). There is some risk that the use of ECN will result in either reset of the ECN field or loss of all packets with ECT or ECN-CE markings. If the path between the sender and the receivers exhibits either of these behaviours, the sender needs to stop using ECN immediately to protect both the network and the application. The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic at any time. This is to ensure that packet loss due to ECN marking will not effect the RTCP traffic and the necessary feedback information it carries. An RTP system that supports ECN MUST implement the initiation of ECN using in-band RTP and RTCP described in Section 7.2.1. It MAY also implement other mechanisms to initiate ECN support, for example, the STUN-based mechanism described in Section 7.2.2, or use the leap-of- faith option if the session supports the limitations provided in Section 7.2.3. If support for both in-band and out-of-band mechanisms is signalled, the sender when negotiating SHOULD offer detection of ECT using STUN with ICE with higher priority than detection of ECT using RTP and RTCP. No matter how ECN usage is initiated, the sender MUST continually monitor the ability of the network, and all its receivers, to support ECN, following the mechanisms described in Section 7.4. This is necessary because path changes or changes in the receiver population may invalidate the ability of the system to use ECN.
Top   ToC   RFC6679 - Page 29

7.2.1. Detection of ECT Using RTP and RTCP

The ECN initiation phase using RTP and RTCP to detect if the network path supports ECN comprises three stages. First, the RTP sender generates some small fraction of its traffic with ECT marks to act as 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. 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 is 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 baseline to compare performance parameters against. Another reason for only probing with a small number of packets is to reduce the risk that significant numbers of congestion markings might be lost if ECT is cleared to not-ECT by an ECN-reverting Middlebox. Then, any resulting lack of congestion response is likely to have little damaging effect on others. An RTP sender is RECOMMENDED to send a minimum of two packets with ECT markings per RTCP reporting interval. In case a random ECT pattern is intended to be used, at least one packet with ECT(0) and one with ECT(1) should be sent per reporting interval; in case a single ECT marking is to be used, only that ECT value SHOULD be sent. The RTP sender SHALL continue to send some ECT-marked traffic as long as the ECN initiation phase continues. The sender SHOULD NOT mark all RTP packets as ECT during the ECN initiation phase. 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 very media dependent. For audio formats, it would make sense for the sender to mark comfort noise packets or similar. For video formats, packets containing P- or B-frames (rather than I-frames) would be an appropriate choice. No matter which RTP packets are marked, those packets MUST NOT be sent in duplicate, with and without ECT, since the RTP sequence number is used to identify packets that are received with ECN markings.
Top   ToC   RFC6679 - Page 30
   Generating RTCP ECN Feedback:  If ECN capability has been negotiated
      in an RTP session, the receivers in the session MUST listen for
      ECT or ECN-CE-marked RTP packets and generate RTCP ECN feedback
      packets (Section 5.1) to mark their receipt.  An immediate or
      early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD
      be generated on receipt of the first ECT- or ECN-CE-marked packet
      from a sender that has not previously sent any ECT traffic.  Each
      regular RTCP report MUST also contain an ECN Summary Report
      (Section 5.2).  Reception of subsequent ECN-CE-marked packets MUST
      result in additional early or immediate ECN feedback packets being
      sent unless no timely feedback is required.

   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 Section 7.3).

      An RTP sender shall consider the group membership to be stable
      after it has been in the session and sending ECT-marked probe
      packets for at least three RTCP reporting intervals (i.e., after
      sending its third regularly scheduled RTCP packet) and when a
      complete RTCP reporting interval has passed without changes to the
      group membership.  ECN initiation is considered successful when
      the group membership is stable and all known participants have
      sent one or more RTCP ECN feedback packets or RTCP XR ECN Summary
      Reports indicating correct receipt of the ECT-marked RTP packets
      generated by the sender.

      As an optimisation, if an RTP sender is initiating ECN usage
      towards a unicast address, then it MAY treat the ECN initiation as
      provisionally successful if it receives an RTCP ECN Feedback
      Report or an RTCP XR ECN Summary Report indicating successful
      receipt of the ECT-marked packets, with no negative indications,
      from a single RTP receiver (where a single RTP receiver is
      considered as all SSRCs used by a single RTCP CNAME).  After
      declaring provisional success, the sender MAY generate ECT-marked
      packets as described in Section 7.3, provided it continues to
      monitor the RTCP reports for a period of three RTCP reporting
      intervals from the time the ECN initiation started, to check if
      there are any other participants in the session.  Thus, as long as
      any additional SSRC that report on the ECN usage are using the
      same RTCP CNAME as the previous reports and they are all
      indicating functional ECN, the sender may continue.  If other
      participants are detected, i.e., other RTCP CNAMEs, the sender
      MUST fallback to only ECT-marking a small fraction of its RTP
Top   ToC   RFC6679 - Page 31
      packets, while it determines if ECN can be supported following the
      full procedure described above.  Different RTCP CNAMEs received
      over a unicast transport may occur when using translators in a
      multi-party RTP session (e.g., when using a centralised conference
      bridge).

         Note: The above optimisation supports peer-to-peer unicast
         transport with several SSRCs multiplexed onto the same flow
         (e.g., a single participant with two video cameras or SSRC
         multiplexed RTP retransmission [RFC4588]).  It is desirable to
         be able to rapidly negotiate ECN support for such a session,
         but the optimisation above can fail if there are
         implementations that use the same CNAME for different parts of
         a distributed implementation that have different transport
         characteristics (e.g., if a single logical endpoint is split
         across multiple hosts).

      ECN initiation is considered to have failed at the instant the
      initiating RTP sender received an RTCP packet that doesn't contain
      an RTCP ECN Feedback Report or ECN Summary Report from any RTP
      session participant that 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.

   If the ECN negotiation succeeds, this indicates that the path can
   pass some ECN-marked traffic and that the receivers support ECN
   feedback.  This does not necessarily imply that the path can robustly
   convey ECN feedback; Section 7.3 describes the ongoing monitoring
   that must be performed to ensure the path continues to robustly
   support ECN.

   When a sender or receiver detects ECN failures on paths, they should
   log these to enable follow up and statistics gathering regarding
   broken paths.  The logging mechanism used is implementation
   dependent.

7.2.2. Detection of ECT Using STUN with ICE

This section describes an OPTIONAL method that can be used to avoid media impact and also ensure an ECN-capable path prior to media transmission. This method is considered in the context where the session participants are using ICE [RFC5245] 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.
Top   ToC   RFC6679 - Page 32
   Note that this method is only applicable to sessions when the remote
   destinations are unicast addresses.  In addition, transport
   translators that do not terminate the ECN control loop and may
   distribute received packets to more than one other receiver must
   either disallow this method (and use the RTP/RTCP method instead) or
   implement additional handling as discussed below.  This is because
   the ICE initialisation method verifies the underlying transport to
   one particular address and port.  If the receiver at that address and
   port intends to use the received packets in a multi-point session,
   then the tested capabilities and the actual session behaviour are not
   matched.

   To minimise the impact of setup delay, and to prioritise the fact
   that one has working connectivity rather than necessarily finding the
   best ECN-capable network path, this procedure is applied after having
   performed a successful connectivity check for a candidate, which is
   nominated for usage.  At that point, an additional connectivity check
   is performed, sending the "ECN-CHECK" attribute in a STUN packet that
   is ECT marked.  On reception of the packet, a STUN server supporting
   this extension will note the received ECN field value and send a
   STUN/UDP/IP packet in reply with the ECN field set to not-ECT and an
   ECN-CHECK attribute included.  A STUN server that doesn't understand
   the extension, or is incapable of reading the ECN values on incoming
   STUN packets, should follow the rule in the STUN specification for
   unknown comprehension-optional attributes and ignore the attribute,
   resulting in the sender receiving a STUN response without the ECN-
   CHECK STUN attribute.

   The ECN STUN checks can be lost on the path, for example, due to the
   ECT marking but also due to various other non ECN-related reasons
   causing packet loss.  The goal is to detect when the ECT markings are
   rewritten or if it is the ECT marking that causes packet loss so that
   the path can be determined as not-ECT.  Other reasons for packet loss
   should not result in a failure to verify the path as ECT.  Therefore,
   a number of retransmissions should be attempted.  But, the sender of
   ECN STUN checks will also have to set a criteria for when it gives up
   testing for ECN capability on the path.  Since the ICE agent has
   successfully verified the path, an RTT measurement for this path can
   be performed.  To have a high probability of successfully verifying
   the path, it is RECOMMENDED that the client retransmit the ECN STUN
   check at least 4 times.  The transmission for that flow is stopped
   when an ECN-CHECK STUN response has been received, which doesn't
   indicate a retransmission of the request due to a temporary error, or
   the maximum number of retransmissions has been sent.  The ICE agent
   is recommended to give up on the ECN verification MAX(1.5*RTT, 20 ms)
   after the last ECN STUN check was sent.
Top   ToC   RFC6679 - Page 33
   The transmission of the ECT-marked STUN connectivity checks
   containing the ECN-CHECK attribute can be done prior as well in
   parallel to actual media transmission.  Both cases are supported,
   where the main difference is how aggressively the transmission of the
   STUN checks are done.  The reason for this is to avoid adding
   additional startup delay until media can flow.  If media is required
   immediately after nomination has occurred, the STUN checks SHALL be
   done in parallel.  If the application does not require media
   transmission immediately, the verification of ECT SHOULD start using
   the aggressive mode.  At any point in the process until ECT has been
   verified or found to not work, media transmission MAY be started, and
   the ICE agent SHALL transition from the aggressive mode to the
   parallel mode.

   The aggressive mode uses an interval between the retransmissions
   based on the Ta timer as defined in Section 16.1 for RTP Media
   Streams in ICE [RFC5245].  The number of ECN STUN checks needing to
   be sent will depend on the number of ECN-capable flows (N) that is to
   be established.  The interval between each transmission of an ECN-
   CHECK packet MUST be Ta.  In other words, for a given flow being
   verified for ECT, the retransmission timeout (RTO) is set to Ta*N.

   The parallel mode uses transmission intervals in order to prevent the
   ECT verification checks from increasing the total bitrate more than
   10%.  As ICE's regular transmission schedule is mimicking a common
   voice call in amount, to meet that goal for most media flows, setting
   the retransmission interval to Ta*N*k where k=10 fulfills that goal.
   Thus, the default behaviour SHALL be to use k=10 when in parallel
   mode.  In cases where the bitrate of the STUN connectivity checks can
   be determined, they MAY be sent with smaller values of k, but k MUST
   NOT be smaller than 1, as long as the total bitrate for the
   connectivity checks are less than 10% of the used media bitrate.  The
   RTP media packets being sent in parallel mode SHALL NOT be ECT marked
   prior to verification of the path as ECT.

   The STUN ECN-CHECK attribute contains one field and a flag, as shown
   in Figure 6.  The flag indicates whether the echo field contains a
   valid value or not.  The field is the ECN echo field and, when valid,
   contains the two ECN bits from the packet it echoes back.  The ECN-
   CHECK attribute is a comprehension optional attribute.
Top   ToC   RFC6679 - Page 34
    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|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Figure 6: ECN-CHECK STUN Attribute

   V: Valid (1 bit) ECN Echo value field is valid when set to 1 and
      invalid when set 0.

   ECF:  ECN Echo value field (2 bits) contains the ECN field value of
      the STUN packet it echoes back when the field is valid.  If
      invalid, the content is arbitrary.

   Reserved:  Reserved bits (29 bits) SHALL be set to 0 on transmission
      and SHALL be ignored on reception.

   This attribute MAY be included in any STUN request to request the ECN
   field to be echoed back.  In STUN requests, the V bit SHALL be set to
   0.  A compliant STUN server receiving a request with the ECN-CHECK
   attribute SHALL read the ECN field value of the IP/UDP packet in
   which the request was received.  Upon forming the response, the
   server SHALL include the ECN-CHECK attribute setting the V bit to
   valid and include the read value of the ECN field into the ECF field.
   If the STUN responder was unable to ascertain, due to temporary
   errors, the ECN value of the STUN request, it SHALL set the V bit in
   the response to 0.  The STUN client may retry immediately.

   The ICE-based initialisation method does require some special
   consideration when used by a translator.  This is especially for
   transport translators and translators that fragment or reassemble
   packets, since they do not separate the ECN control loops between the
   endpoints and the translator.  When using ICE-based initiation, such
   a translator must ensure that any participants joining an RTP session
   for which ECN has been negotiated are successfully verified in the
   direction from the translator to the joining participant.
   Alternatively, it must correctly handle remarking of ECT RTP packets
   towards that participant.  When a new participant joins the session,
   the translator will perform a check towards the new participant.  If
   that is successfully completed, the ECT properties of the session are
   maintained for the other senders in the session.  If the check fails,
   then the existing senders will now see a participant that fails to
   receive ECT.  Thus, the failure detection in those senders will
   eventually detect this.  However, to avoid misusing the network on
   the path from the translator to the new participant, the translator
Top   ToC   RFC6679 - Page 35
   SHALL remark the traffic intended to be forwarded from ECT to not-
   ECT.  Any packets intended to be forwarded that are ECN-CE marked
   SHALL be discarded and not sent.  In cases where the path from a new
   participant to the translator fails the ECT check, then only that
   sender will not contribute any ECT-marked traffic towards the
   translator.

7.2.3. Leap-of-Faith ECT Initiation Method

This method for initiating ECN usage is a leap of faith that assumes that ECN will work on the used path(s). The method is to go directly to "ongoing use of ECN" as defined in Section 7.3. Thus, all RTP packets MAY be marked as ECT, and the failure detection MUST be used to detect any case when the assumption that the path is ECT capable is wrong. This method is only recommended for controlled environments where the whole path(s) between sender and receiver(s) has been built and verified to be ECT. If the sender marks all packets as ECT while transmitting on a path that contains an ECN-blocking middlebox, then receivers downstream of that middlebox will not receive any RTP data packets from the sender and hence will not consider it to be an active RTP SSRC. The sender can detect this and revert to sending packets without ECT marks, since RTCP SR/RR packets from such receivers will either not include a report for the sender's SSRC or will report that no packets have been received, but this takes at least one RTCP reporting interval. It should be noted that a receiver might generate its first RTCP packet immediately on joining a unicast session, or very shortly after joining an RTP/AVPF session, before it has had chance to receive any data packets. A sender that receives an RTCP SR/RR packet indicating lack of reception by a receiver SHOULD therefore wait for a second RTCP report from that receiver to be sure that the lack of reception is due to ECT-marking. Since this recovery process can take several tens of seconds, during which time the RTP session is unusable for media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation method be used in environments where ECN-blocking middleboxes are likely to be present.

7.3. Ongoing Use of ECN within an RTP Session

Once ECN has been successfully initiated for an RTP sender, that sender begins sending all RTP data packets as ECT-marked, and its receivers send ECN feedback information via RTCP packets. This section describes procedures for sending ECT-marked data, providing ECN feedback information via RTCP, and responding to ECN feedback information.
Top   ToC   RFC6679 - Page 36

7.3.1. Transmission of ECT-Marked RTP Packets

After a sender has successfully initiated ECN use, it SHOULD mark all the RTP data packets it sends as ECT. The sender SHOULD mark packets as ECT(0) unless the receiver expresses a preference for ECT(1) or for a random ECT value using the "ect" parameter in the "a=ecn-- capable-rtp:" attribute. The sender SHALL NOT include ECT marks on outgoing RTCP packets and SHOULD NOT include ECT marks on any other outgoing control messages (e.g., STUN [RFC5389] packets, Datagram Transport Layer Security (DTLS) [RFC6347] handshake packets, or ZRTP [RFC6189] control packets) that are multiplexed on the same UDP port. For control packets there might be exceptions, like the STUN-based ECN-CHECK defined in Section 7.2.2.

7.3.2. Reporting ECN Feedback via RTCP

An RTP receiver that receives a packet with an ECN-CE mark, or that detects a packet loss, MUST schedule the transmission of an RTCP ECN feedback packet as soon as possible (subject to the constraints of [RFC4585] and [RFC3550]) to report this back to the sender unless no timely feedback is required. The feedback RTCP packet SHALL consist of at least one ECN feedback packet (Section 5.1) reporting on the packets received since the last ECN feedback packet and will contain (at least) an RTCP SR/RR packet and an SDES packet, unless reduced- size RTCP [RFC5506] is used. The RTP/AVPF profile in early or immediate feedback mode SHOULD be used where possible, to reduce the interval before feedback can be sent. To reduce the size of the feedback message, reduced-size RTCP [RFC5506] MAY be used if supported by the endpoints. Both RTP/AVPF and reduced-size RTCP MUST be negotiated in the session setup signalling before they can be used. Every time a regular compound RTCP packet is to be transmitted, an ECN-capable RTP receiver MUST include an RTCP XR ECN Summary Report as described in Section 5.2 as part of the compound packet. The multicast feedback implosion problem, which occurs when many receivers simultaneously send feedback to a single sender, must be considered. The RTP/AVPF transmission rules will limit the amount of feedback that can be sent, avoiding the implosion problem but also delaying feedback by varying degrees from nothing up to a full RTCP reporting interval. As a result, the full extent of a congestion situation may take some time to reach the sender, although some feedback should arrive in a reasonably timely manner, allowing the sender to react on a single or a few reports.
Top   ToC   RFC6679 - Page 37

7.3.3. Response to Congestion Notifications

The reception of RTP packets with ECN-CE marks in the IP header is a notification that congestion is being experienced. The default reaction on the reception of these ECN-CE-marked packets MUST be to provide the congestion control algorithm with a congestion notification that triggers the algorithm to react as if packet loss had occurred. There should be no difference in congestion response if ECN-CE marks or packet drops are detected. Other reactions to ECN-CE may be specified in the future, following IETF Review. Detailed designs of such alternative reactions MUST be specified in a Standards Track RFC and be reviewed to ensure they are safe for deployment under any restrictions specified. A potential example for an alternative reaction could be emergency communications (such as that generated by first responders, as opposed to the general public) in networks where the user has been authorised. A more detailed description of these other reactions, as well as the types of congestion control algorithms used by end-nodes, is outside the scope of this document. Depending on the media format, type of session, and RTP topology used, there are several different types of congestion control that can be used: Sender-Driven Congestion Control: The sender is responsible for adapting the transmitted bitrate in response to RTCP ECN feedback. When the sender receives the ECN feedback data, it feeds this information into its congestion control or bitrate adaptation mechanism so that it can react as if packet loss was reported. The congestion control algorithm to be used is not specified here, although TFRC [RFC5348] is one example that might be used. Receiver-Driven Congestion Control: In a receiver-driven congestion control mechanism, the receivers can react to the ECN-CE marks themselves without providing ECN-CE feedback to the sender. This may allow faster response than sender-driven congestion control in some circumstances and also scale to large number of receivers and multicast usage. One example of receiver-driven congestion control is implemented by providing the content in a layered way, with each layer providing improved media quality but also increased bandwidth usage. The receiver locally monitors the ECN-CE marks on received packets to check if it experiences congestion with the current number of layers. If congestion is experienced, the receiver drops one layer, thus reducing the resource consumption on the path towards itself. For example, if a layered media encoding scheme such as H.264 Scalable Video Coding (SVC) is used, the receiver may change its layer
Top   ToC   RFC6679 - Page 38
      subscription and so reduce the bitrate it receives.  The receiver
      MUST still send an RTCP XR ECN Summary to the sender, even if it
      can adapt without contact with the sender, so that the sender can
      determine if ECN is supported on the network path.  The timeliness
      of RTCP feedback is less of a concern with receiver-driven
      congestion control, and regular RTCP reporting of ECN summary
      information is sufficient (without using RTP/AVPF immediate or
      early feedback).

   Hybrid:  There might be mechanisms that utilise both some receiver
      behaviours and some sender-side monitoring, thus requiring both
      feedback of congestion events to the sender and taking receiver
      decisions and possible signalling to the sender.  In this case,
      the congestion control algorithm needs to use the signalling to
      indicate which features of ECN for RTP are required.

   Responding to congestion indication in the case of multicast traffic
   is a more complex problem than for unicast traffic.  The fundamental
   problem is diverse paths, i.e., when different receivers don't see
   the same path and thus have different bottlenecks, so the receivers
   may get ECN-CE-marked packets due to congestion at different points
   in the network.  This is problematic for sender-driven congestion
   control, since when receivers are heterogeneous in regards to
   capacity, the sender is limited to transmitting at the rate the
   slowest receiver can support.  This often becomes a significant
   limitation as group size grows.  Also, as group size increases, the
   frequency of reports from each receiver decreases, which further
   reduces the responsiveness of the mechanism.  Receiver-driven
   congestion control has the advantage that each receiver can choose
   the appropriate rate for its network path, rather than all receivers
   having to settle for the lowest common rate.

   We note that ECN support is not a silver bullet to improving
   performance.  The use of ECN gives the chance to respond to
   congestion before packets are dropped in the network, improving the
   user experience by allowing the RTP application to control how the
   quality is reduced.  An application that ignores ECN Congestion
   Experienced feedback is not immune to congestion: the network will
   eventually begin to discard packets if traffic doesn't respond.  To
   avoid packet loss, it is in the best interest of an application to
   respond to ECN congestion feedback promptly.

7.4. Detecting Failures

Senders and receivers can deliberately ignore ECN-CE and thus get a benefit over behaving flows (cheating). The ECN nonce [RFC3540] is an addition to TCP that attempts to solve this issue as long as the sender acts on behalf of the network. The assumption that senders
Top   ToC   RFC6679 - Page 39
   act on behalf of the network may be false due to the nature of peer-
   to-peer use of RTP.  Still, a significant portion of RTP senders are
   infrastructure devices (for example, streaming media servers) that do
   have an interest in protecting both service quality and the network.
   Even though there may be cases where the nonce may be applicable for
   RTP, it is not included in this specification.  This is because a
   receiver interested in cheating would simply claim to not support the
   nonce, or even ECN itself.  It is, however, worth mentioning that, as
   real-time media is commonly sensitive to increased delay and packet
   loss, it will be in the interest of both the media sender and
   receivers to minimise the number and duration of any congestion
   events as they will adversely affect media quality.

   RTP sessions can also suffer from path changes resulting in a non-
   ECN-compliant node becoming part of the path.  That node may perform
   either of two actions that has an effect on the ECN and application
   functionality.  The gravest is if the node drops packets with the ECN
   field set to ECT(0), ECT(1), or ECN-CE.  This can be detected by the
   receiver when it receives an RTCP SR packet indicating that a sender
   has sent a number of packets that it has not received.  The sender
   may also detect such a middlebox based on the receiver's RTCP RR
   packet, when the extended sequence number is not advanced due to the
   failure to receive packets.  If the packet loss is less than 100%,
   then packet loss reporting in either the ECN feedback information or
   RTCP RR will indicate the situation.  The other action is to re-mark
   a packet from ECT or ECN-CE to not-ECT.  That has less dire results;
   however, it should be detected so that ECN usage can be suspended to
   prevent misusing the network.

   The RTCP XR ECN summary packet and the ECN feedback packet allow the
   sender to compare the number of ECT-marked packets of different types
   received with the number it actually sent.  The number of ECT packets
   received, plus the number of ECN-CE-marked and lost packets, should
   correspond to the number of sent ECT-marked packets plus the number
   of received duplicates.  If these numbers don't agree, there are two
   likely reasons: a translator changing the stream or not carrying the
   ECN markings forward or some node re-marking 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 behaviour is happening on the path.

   Thus, packet losses and non-matching ECN field value statistics are
   possible indications of issues with using ECN over the path.  The
   next section defines both sender and receiver reactions to these
   cases.
Top   ToC   RFC6679 - Page 40

7.4.1. Fallback Mechanisms

Upon the detection of a potential failure, both the sender and the receiver can react to mitigate the situation. A receiver that detects a packet loss burst MAY schedule an early feedback packet that includes at least the RTCP RR and the ECN feedback message to report this to the sender. This will speed up the detection of the loss at the sender, thus triggering sender-side mitigation. A sender that detects high packet loss rates for ECT-marked packets SHOULD immediately switch to sending packets as not-ECT to determine if the losses are potentially due to the ECT markings. If the losses disappear when the ECT-marking is discontinued, the RTP sender should go back to initiation procedures to attempt to verify the apparent loss of ECN capability of the used path. If a re-initiation fails, then two possible actions exist: 1. Periodically retry the ECN initiation to detect if a path change occurs to a path that is ECN capable. 2. Renegotiate the session to disable ECN support. This is a choice that is suitable if the impact of ECT probing on the media quality is noticeable. If multiple initiations have been successful, but the following full usage of ECN has resulted in the fallback procedures, then disabling of the ECN support is RECOMMENDED. We foresee the possibility of flapping ECN capability due to several reasons: video-switching MCU or similar middleboxes that select to deliver media from the sender only intermittently; load-balancing devices that may in worst case result in some packets taking a different network path than the others; mobility solutions that switch the underlying network path in a transparent way for the sender or receiver; and membership changes in a multicast group. It is, however, appropriate to mention that there are also issues such as re-routing of traffic due to a flappy route table or excessive reordering and other issues that are not directly ECN related but nevertheless may cause problems for ECN.

7.4.2. Interpretation of ECN Summary Information

This section contains discussion on how the ECN Summary Report information can be used to detect various types of ECN path issues. We first review the information the RTCP reports provide on a per- source (SSRC) basis:
Top   ToC   RFC6679 - Page 41
   ECN-CE Counter:  The number of RTP packets received so far in the
      session with an ECN field set to CE.

   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.

   not-ECT Counter:  The number of RTP packets received so far in the
      session with an ECN field set to not-ECT.

   Lost Packets Counter:  The number of RTP packets that where expected
      based on sequence numbers but never received.

   Duplication Counter:  The number of received RTP packets that are
      duplicates of already received ones.

   Extended Highest Sequence number:  The highest sequence number seen
      when sending this report, but with additional bits, to handle
      disambiguation when wrapping the RTP sequence number field.

   The counters will be initialised to zero to provide values for the
   RTP stream sender from the first report.  After the first report, the
   changes between the last received report and the previous report are
   determined by simply taking the values of the latest minus the
   previous, taking wrapping into account.  This definition is also
   robust to packet losses, since if one report is missing, the
   reporting interval becomes longer, but is otherwise equally valid.

   In a perfect world, the number of not-ECT packets received should be
   equal to the number sent minus the Lost Packets Counter, and the sum
   of the ECT(0), ECT(1), and ECN-CE counters should be equal to the
   number of ECT-marked packet sent.  Two issues may cause a mismatch in
   these statistics: severe network congestion or unresponsive
   congestion control might cause some ECT-marked packets to be lost,
   and packet duplication might result in some packets being received
   and counted in the statistics multiple times (potentially with a
   different ECN-mark on each copy of the duplicate).

   The rate of packet duplication is tracked, allowing one to take the
   duplication into account.  The value of the ECN field for duplicates
   will also be counted, and when comparing the figures, one needs to
   take into account in the calculation that some fraction of packet
   duplicates are not-ECT and some are ECT.  Thus, when only sending
   not-ECT, the number of sent packets plus reported duplicates equals
   the number of received not-ECT.  When sending only ECT, the number of
   sent ECT packets plus duplicates will equal ECT(0), ECT(1), ECN-CE,
   and packet loss.  When sending a mix of not-ECT and ECT, there is an
   uncertainty if any duplicate or packet loss was an not-ECT or ECT.
   If the packet duplication is completely independent of the usage of
Top   ToC   RFC6679 - Page 42
   ECN, then the fraction of packet duplicates should be in relation to
   the number of not-ECT vs. ECT packets sent during the period of
   comparison.  This relation does not hold for packet loss, where
   higher rates of packet loss for not-ECT is expected than for ECT
   traffic.

   Detecting clearing of ECN field: If the ratio between ECT and not-ECT
   transmitted in the reports has become all not-ECT, or has
   substantially changed towards not-ECT, then this is clearly an
   indication that the path results in clearing of the ECT field.

   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
   is low in either of the categories.  One must also take into account
   the level of CE marking.  A CE-marked packet would have been dropped
   unless it was ECT marked.  Thus, the packet loss level for not-ECT
   should be approximately equal to the loss rate for ECT when counting
   the CE-marked packets as lost ones.  A sender performing this
   calculation needs to ensure that the difference is statistically
   significant.

   If erroneous behaviour is detected, it should be logged to enable
   follow up and statistics gathering.



(page 42 continued on part 3)

Next Section