idnits 2.17.1 draft-ietf-avtcore-ecn-for-rtp-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 14, 2011) is 4792 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'TBA1' is mentioned on line 711, but not defined == Missing Reference: 'TBA2' is mentioned on line 842, but not defined == Outdated reference: A later version (-02) exists of draft-ietf-mmusic-ice-options-registry-00 ** Downref: Normative reference to an Experimental RFC: RFC 2762 ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Westerlund 3 Internet-Draft I. Johansson 4 Intended status: Standards Track Ericsson 5 Expires: September 15, 2011 C. Perkins 6 University of Glasgow 7 P. O'Hanlon 8 UCL 9 K. Carlberg 10 G11 11 March 14, 2011 13 Explicit Congestion Notification (ECN) for RTP over UDP 14 draft-ietf-avtcore-ecn-for-rtp-01 16 Abstract 18 This document specifies how explicit congestion notification (ECN) 19 can be used with Real-time Transport Protocol (RTP) over UDP flows 20 that use RTP Control Protocol (RTCP) as feedback mechanism. It 21 defines one RTP Control Protocol Extended Reports (RTCP XR) extension 22 for ECN summary, a RTCP transport feedback format for timely 23 reporting of congestion events, and an Session Traversal Utilities 24 for NAT (STUN) extension used in the optional initilization method 25 using Interactive Connectivity Establishment (ICE). Signalling and 26 procedures for negotiation of capabilities and initilization methods 27 are also defined. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 15, 2011. 46 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 5 65 3. Discussion, Requirements, and Design Rationale . . . . . . . . 6 66 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 8 67 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 68 3.3. Interoperability . . . . . . . . . . . . . . . . . . . . . 12 69 4. Overview of Use of ECN with RTP/UDP/IP . . . . . . . . . . . . 12 70 5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 15 71 5.1. RTP/AVPF Transport Layer ECN Feedback packet . . . . . . . 16 72 5.2. RTCP XR Report block for ECN summary information . . . . . 19 73 6. SDP Signalling Extensions for ECN . . . . . . . . . . . . . . 20 74 6.1. Signalling ECN Capability using SDP . . . . . . . . . . . 20 75 6.2. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 24 76 6.3. XR Block SDP Parameter . . . . . . . . . . . . . . . . . . 25 77 6.4. ICE Parameter to Signal ECN Capability . . . . . . . . . . 25 78 7. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 25 79 7.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 26 80 7.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 26 81 7.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 32 82 7.4. Detecting Failures . . . . . . . . . . . . . . . . . . . . 35 83 8. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 38 84 8.1. Fragmentation and Reassembly in Translators . . . . . . . 38 85 8.2. Generating RTCP ECN Feedback in Media Transcoders . . . . 40 86 8.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 41 87 9. Implementation considerations . . . . . . . . . . . . . . . . 42 88 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 89 10.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 42 90 10.2. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 42 91 10.3. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 43 92 10.4. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 43 93 10.5. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 43 94 10.6. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 43 95 10.7. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 43 96 11. Security Considerations . . . . . . . . . . . . . . . . . . . 43 97 12. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 46 98 12.1. Basic SDP Offer/Answer . . . . . . . . . . . . . . . . . . 46 99 12.2. Declarative Multicast SDP . . . . . . . . . . . . . . . . 48 100 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 49 101 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 102 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 50 103 15.1. Normative References . . . . . . . . . . . . . . . . . . . 50 104 15.2. Informative References . . . . . . . . . . . . . . . . . . 51 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 107 1. Introduction 109 This document outlines how Explicit Congestion Notification (ECN) 110 [RFC3168] can be used for Real-time Transport Protocol (RTP) 111 [RFC3550] flows running over UDP/IP which use RTP Control Protocol 112 (RTCP) as a feedback mechanism. The solution consists of feedback of 113 ECN congestion experienced markings to the sender using RTCP, 114 verification of ECN functionality end-to-end, and how to initiate ECN 115 usage. The initiation process will have some dependencies on the 116 signalling mechanism used to establish the RTP session, a 117 specification for signalling mechanisms using Session Description 118 Protocol (SDP) [RFC4566] is included. 120 ECN is getting attention as a method to minimise the impact of 121 congestion on real-time multimedia traffic. When ECN is used, the 122 network can signal to applications that congestion is occurring, 123 whether that congestion is due to queuing at a congested link, 124 limited resources and coverage on a radio link, or other reasons. 126 ECN provides a way for networks to send congestion control signals to 127 a media transport without having to impair the media. Unlike losses, 128 the signals unambiguously indicate congestion to the transport as 129 quickly as feedback delays allow, and without confusing congestion 130 with losses that might have occurred for other reasons such as 131 transmission errors, packet-size errors, routing errors, badly 132 implemented middleboxes, policy violations and so forth. 134 The introduction of ECN into the Internet requires changes to both 135 the network and transport layers. At the network layer, IP 136 forwarding has to be updated to allow routers to mark packets, rather 137 than discarding them in times of congestion [RFC3168]. In addition, 138 transport protocols have to be modified to inform the sender that ECN 139 marked packets are being received, so it can respond to the 140 congestion. TCP [RFC3168], SCTP [RFC4960] and DCCP [RFC4340] have 141 been updated to support ECN, but to date there is no specification 142 how UDP-based transports, such as RTP [RFC3550], can use ECN. This 143 is due to the lack of feedback mechanisms directly in UDP. Instead 144 the signaling control protocol on top of UDP needs to provide that 145 feedback, which for RTP is RTCP. 147 The remainder of this memo is structured as follows. We start by 148 describing the conventions, definitions and acronyms used in this 149 memo in Section 2, and the design rationale and applicability in 150 Section 3. Section 4 provides an overview of how ECN is used with 151 RTP over UDP. Then the definition of the RTCP extensions for ECN 152 feedback in Section 5. Then the SDP signalling extensions required 153 are specified Section 6.Then the full details of how ECN is used with 154 RTP over UDP is defined in Section 7. In Section 8 we discuss how 155 RTCP ECN feedback is handled in RTP translators and mixers. 156 Section 9 discusses some implementation considerations, Section 10 157 lists IANA considerations, and Section 11 discusses the security 158 considerations. 160 2. Conventions, Definitions and Acronyms 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 164 "OPTIONAL" in this document are to be interpreted as described in RFC 165 2119 [RFC2119]. 167 Abbreviations 169 o ECN: Explicit Congestion Notification 171 o ECT: ECN Capable Transport 173 o ECN-CE: ECN Congestion Experienced 175 o not-ECT: Not ECN Capable Transport 177 This document uses the terms sender and receiver according to the 178 following definition: 180 Sender: Sender of RTP packets carrying an encoded media stream. The 181 sender has the possibility to effect how this transmission is 182 performed. It is one end-point of the ECN control loop. 184 Receiver: A receiver of RTP packets with the intention to consume 185 the media stream in some form. It sends RTCP feedback on the 186 received stream. It is the other end-point of the ECN control 187 loop. 189 Note: RTP mixers or translators that operate in such a manner that 190 they terminate or split the ECN control loop will take on the role of 191 receivers or senders. This is further discussed in Section 3.2. 193 The meaning of the term ECN support depends on which entity between 194 the sender and receiver (inclusive) that is considered. We 195 distinguish between: 197 o ECN-Capable Host: Sender or receiver of media. 199 o ECN-Capable Transport: ECT = all ends are ECN capable hosts. 201 o ECN-Capable Packets: Packets are either ECT or CE. 203 o ECN-Oblivious Relay: Router or middlebox that treats ECN-Capable 204 Packets no differently from Not-ECT. 206 o ECN-Capable Queue: Supports ECN marking of ECN-Capable Packets. 208 o ECN-Blocking Middlebox: Discards ECN-Capable Packets. 210 o ECN-Reverting Middlebox: Changes ECN-Capable Packets to Not-ECT. 212 3. Discussion, Requirements, and Design Rationale 214 ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960], 215 and DCCP [RFC4340] transports. These are all unicast protocols which 216 negotiate the use of ECN during the initial connection establishment 217 handshake (supporting incremental deployment, and checking if ECN 218 marked packets pass all middleboxes on the path). ECN Congestion 219 Experienced (ECN-CE) marks are immediately echoed back to the sender 220 by the receiving end-point using an additional bit in feedback 221 messages, and the sender then interprets the mark as equivalent to a 222 packet loss for congestion control purposes. 224 If RTP is run over TCP, SCTP, or DCCP, it can use the native ECN 225 support provided by those protocols. This memo does not concern 226 itself further with these use cases. However, RTP is more commonly 227 run over UDP. This combination does not currently support ECN, and 228 we observe that it has significant differences from the other 229 transport protocols for which ECN has been specified. These include: 231 Signalling: RTP relies on separate signalling protocols to negotiate 232 parameters before a session can be created, and doesn't include an 233 in-band handshake or negotiation at session set-up time (i.e. 234 there is no equivalent to the TCP three-way handshake in RTP). 236 Feedback: RTP does not explicitly acknowledge receipt of datagrams. 237 Instead, the RTP Control Protocol (RTCP) provides reception 238 quality feedback, and other back channel communication, for RTP 239 sessions. The feedback interval is generally on the order of 240 seconds, rather than once per network RTT (although the RTP/AVPF 241 profile [RFC4585] allows more rapid feedback in most cases). 243 Congestion Response: While it is possible to adapt the transmission 244 of many audio/visual streams in response to network congestion, 245 and such adaptation is required by [RFC3550], the dynamics of the 246 congestion response may be quite different to those of TCP or 247 other transport protocols. 249 Middleboxes: The RTP framework explicitly supports the concept of 250 mixers and translators, which are middleboxes that are involved in 251 media transport functions. 253 Multicast: RTP is explicitly a group communication protocol, and was 254 designed from the start to support IP multicast (primarily ASM, 255 although a recent extension supports SSM with unicast feedback 256 [RFC5760]). 258 Application Awareness: ECN support via TCP, DCCP, and SCTP constrain 259 the awareness and reaction to packet loss within those protocols. 260 By adding support of ECN through RTCP, the application is made 261 aware of packet loss and may choose one or more approaches in 262 response to that loss. 264 Counting vs Detecting Congestion: TCP and the protocols derived from 265 it are mainly designed to respond the same whether they experience 266 a burst of congestion indications within one RTT or just one. 267 Whereas real-time applications may be concerned with the amount of 268 congestion experienced, whether it is distributed smoothly or in 269 bursts. When feedback of ECN was added to TCP [RFC3168], the 270 receiver was designed to flip the echo congestion experienced 271 (ECE) flag to 1 for a whole RTT then flop it back to zero. 272 Whereas ECN feedback in RTCP will need to report a count of how 273 much congestion has been experienced within an RTCP reporting 274 period, irrespective of round trip times. 276 These differences will significantly alter the shape of ECN support 277 in RTP-over-UDP compared to ECN support in TCP, SCTP, and DCCP, but 278 do not invalidate the need for ECN support. 280 ECN support is more important for RTP sessions than, for instance, is 281 the case for TCP. This is because the impact of packet loss in real- 282 time audio-visual media flows is highly visible to users. Effective 283 ECN support for RTP flows running over UDP will allow real-time 284 audio-visual applications to respond to the onset of congestion 285 before routers are forced to drop packets, allowing those 286 applications to control how they reduce their transmission rate, and 287 hence media quality, rather than responding to, and trying to conceal 288 the effects of unpredictable packet loss. Furthermore, widespread 289 deployment for ECN and active queue management in routers, should it 290 occur, can potentially reduce unnecessary queueing delays in routers, 291 lowering the round-trip time and benefiting interactive applications 292 of RTP, such as voice telephony. 294 3.1. Requirements 296 Considering ECN, transport protocols supporting ECN, and RTP based 297 applications one can create a set of requirements that must be 298 satisfied to at least some degree if ECN is to used by RTP over UDP. 300 o REQ 1: A mechanism MUST negotiate and initiate the usage of ECN 301 for RTP/UDP/IP sessions so that an RTP sender will not send 302 packets with ECT in the IP header unless it knows all potential 303 receivers will understand any CE indications they might receive. 305 o REQ 2: A mechanism MUST feedback the reception of any packets that 306 are ECN-CE marked to the packet sender 308 o REQ 3: Provided mechanism SHOULD minimise the possibility for 309 cheating 311 o REQ 4: Some detection and fallback mechanism SHOULD exist to avoid 312 loss of communication due to the attempted usage of ECN in case an 313 intermediate node clears ECT or drops packets that are ECT marked. 315 o REQ 5: Negotiation of ECN SHOULD NOT significantly increase the 316 time taken to negotiate and set-up the RTP session (an extra RTT 317 before the media can flow is unlikely to be acceptable for some 318 use cases). 320 o REQ 6: Negotiation of ECN SHOULD NOT cause media clipping at the 321 start of a session. 323 The following sections describes how these requirements can be meet 324 for RTP over UDP. 326 3.2. Applicability 328 The use of ECN with RTP over UDP is dependent on negotiation of ECN 329 capability between the sender and receiver(s), and validation of ECN 330 support in all elements of the network path(s) traversed. RTP is 331 used in a heterogeneous range of network environments and topologies, 332 with various different signalling protocols, all of which need to be 333 verified to support ECN before it can be used. 335 Due to the need for each RTP sender that intended to use ECN with RTP 336 to track all participants in the RTP session the sub-sampling of the 337 group membership as specified by "Sampling of the Group Membership in 338 RTP" [RFC2762] MUST NOT be used. 340 The usage of ECN is further dependent on a capability of the RTP 341 media flow to react to congestion signalled by ECN marked packets. 343 Depending on the application, media codec, and network topology, this 344 adaptation can occur in various forms and at various nodes. As an 345 example, the sender can change the media encoding, or the receiver 346 can change the subscription to a layered encoding, or either reaction 347 can be accomplished by a transcoding middlebox. RFC 5117 identifies 348 seven topologies in which RTP sessions may be configured, and which 349 may affect the ability to use ECN: 351 Topo-Point-to-Point: This is a standard unicast flow. ECN may be 352 used with RTP in this topology in an analogous manner to its use 353 with other unicast transport protocols, with RTCP conveying ECN 354 feedback messages. 356 Topo-Multicast: This is either an any source multicast (ASM) group 357 [RFC3569] with potentially several active senders and multicast 358 RTCP feedback, or a source specific multicast (SSM) group 359 [RFC4607] with a single sender and unicast RTCP feedback from 360 receivers. RTCP is designed to scale to large group sizes while 361 avoiding feedback implosion (see Section 6.2 of [RFC3550], 362 [RFC4585], and [RFC5760]), and can be used by a sender to 363 determine if all its receivers, and the network paths to those 364 receivers, support ECN (see Section 7.2). It is somewhat more 365 difficult to determine if all network paths from all senders to 366 all receivers support ECN. Accordingly, we allow ECN to be used 367 by an RTP sender using multicast UDP provided the sender has 368 verified that the paths to all known receivers support ECN, and 369 irrespective of whether the paths from other senders to their 370 receivers support ECN. "all its known receivers" are all the SSRCs 371 that the RTP sender has received RTP or RTCP from the last five 372 reporting intervals, i.e. they are not timed out. Note that group 373 membership may change during the lifetime of a multicast RTP 374 session, potentially introducing new receivers that are not ECN 375 capable or have a path that doesn't support ECN. Senders must use 376 the mechanisms described in Section 7.4 to monitor that all 377 receivers continue to support ECN, and they need to fallback to 378 non-ECN use if any senders do not. 380 Topo-Translator: An RTP translator is an RTP-level middlebox that is 381 invisible to the other participants in the RTP session (although 382 it is usually visible in the associated signalling session). 383 There are two types of RTP translator: those do not modify the 384 media stream, and are concerned with transport parameters, for 385 example a multicast to unicast gateway; and those that do modify 386 the media stream, for example transcoding between different media 387 codecs. A single RTP session traverses the translator, and the 388 translator must rewrite RTCP messages passing through it to match 389 the changes it makes to the RTP data packets. A legacy, ECN- 390 unaware, RTP translator is expected to ignore the ECN bits on 391 received packets, and to set the ECN bits to not-ECT when sending 392 packets, so causing ECN negotiation on the path containing the 393 translator to fail (any new RTP translator that does not wish to 394 support ECN may do so similarly). An ECN aware RTP translator may 395 act in one of three ways: 397 * If the translator does not modify the media stream, it should 398 copy the ECN bits unchanged from the incoming to the outgoing 399 datagrams, unless it is overloaded and experiencing congestion, 400 in which case it may mark the outgoing datagrams with an ECN-CE 401 mark. Such a translator passes RTCP feedback unchanged. 403 * If the translator modifies the media stream to combine or split 404 RTP packets, but does not otherwise transcode the media, it 405 must manage the ECN bits in a way analogous to that described 406 in Section 5.3 of [RFC3168]: if an ECN marked packet is split 407 into two, then both the outgoing packets must be ECN marked 408 identically to the original; if several ECN marked packets are 409 combined into one, the outgoing packet must be either ECN-CE 410 marked or dropped if any of the incoming packets are ECN-CE 411 marked. If the outgoing combined packet is not ECN-CE marked, 412 then it MUST be ECT marked if any of the incoming packets were 413 ECT marked. When RTCP ECN feedback packets (Section 5) are 414 received, they must be rewritten to match the modifications 415 made to the media stream (see Section 8.1). 417 * If the translator is a media transcoder, the output RTP media 418 stream may have radically different characteristics than the 419 input RTP media stream. Each side of the translator must then 420 be considered as a separate transport connection, with its own 421 ECN processing. This requires the translator interpose itself 422 into the ECN negotiation process, effectively splitting the 423 connection into two parts with their own negotiation. Once 424 negotiation has been completed, the translator must generate 425 RTCP ECN feedback back to the source based on its own 426 reception, and must respond to RTCP ECN feedback received from 427 the receiver(s) (see Section 8.2). 429 It is recognised that ECN and RTCP processing in an RTP translator 430 that modifies the media stream is non-trivial. 432 Topo-Mixer: A mixer is an RTP-level middlebox that aggregates 433 multiple RTP streams, mixing them together to generate a new RTP 434 stream. The mixer is visible to the other participants in the RTP 435 session, and is also usually visible in the associated signalling 436 session. The RTP flows on each side of the mixer are treated 437 independently for ECN purposes, with the mixer generating its own 438 RTCP ECN feedback, and responding to ECN feedback for data it 439 sends. Since connections are treated independently, it would seem 440 reasonable to allow the transport on one side of the mixer to use 441 ECN, while the transport on the other side of the mixer is not ECN 442 capable, if this is desired. 444 Topo-Video-switch-MCU: A video switching MCU receives several RTP 445 flows, but forwards only one of those flows onwards to the other 446 participants at a time. The flow that is forwarded changes during 447 the session, often based on voice activity. Since only a subset 448 of the RTP packets generated by a sender are forwarded to the 449 receivers, a video switching MCU can break ECN negotiation (the 450 success of the ECN negotiation may depend on the voice activity of 451 the participant at the instant the negotiation takes place - shout 452 if you want ECN). It also breaks congestion feedback and 453 response, since RTP packets are dropped by the MCU depending on 454 voice activity rather than network congestion. This topology is 455 widely used in legacy products, but is NOT RECOMMENDED for new 456 implementations and cannot be used with ECN. 458 Topo-RTCP-terminating-MCU: In this scenario, each participant runs 459 an RTP point-to-point session between itself and the MCU. Each of 460 these sessions is treated independently for the purposes of ECN 461 and RTCP feedback, potentially with some using ECN and some not. 463 Topo-Asymmetric: It is theoretically possible to build a middlebox 464 that is a combination of an RTP mixer in one direction and an RTP 465 translator in the other. To quote RFC 5117 "This topology is so 466 problematic and it is so easy to get the RTCP processing wrong, 467 that it is NOT RECOMMENDED to implement this topology." 469 These topologies may be combined within a single RTP session. 471 The ECN mechanism defined in this memo is applicable to both sender 472 and receiver controlled congestion algorithms. The mechanism ensures 473 that both senders and receivers will know about ECN-CE markings and 474 any packet losses. Thus the actual decision point for the congestion 475 control is not relevant. This is a great benefit as the rate of an 476 RTP session can be varied in a number of ways, for example a unicast 477 media sender might use TFRC [RFC5348] or some other algorithm, while 478 a multicast session could use a sender based scheme adapting to the 479 lowest common supported rate, or a receiver driven mechanism using 480 layered coding to support more heterogeneous paths. 482 To ensure timely feedback of CE marked packets when needed, this 483 mechanism requires support for the RTP/AVPF profile [RFC4585] or any 484 of its derivatives, such as RTP/SAVPF [RFC5124]. The standard RTP/ 485 AVP profile [RFC3551] does not allow any early or immediate 486 transmission of RTCP feedback, and has a minimal RTCP interval whose 487 default value (5 seconds) is many times the normal RTT between sender 488 and receiver. 490 3.3. Interoperability 492 The interoperability requirements for this specification are that 493 there is at least one common interoperability point for all 494 implementations. Since initialization using RTP and RTCP is the one 495 method that works in all cases, although is not optimal for all 496 usages, it is selected as mandatory to implement this initialisation 497 method. This method requires both the RTCP XR extension and the ECN 498 feedback format, which requires the RTP AVPF profile to ensure timely 499 feedback. 501 When one considers all the uses of ECN for RTP it is clear that 502 congestion control mechanisms that are receiver driven only 503 (Section 7.3.3) do not require timely feedback of congestion events. 504 If such a congestion control mechanism is combined with an 505 initialization method that also doesn't require timely feedback using 506 RTCP, like the leap of faith or the ICE based method then neither the 507 ECN feedback format nor AVPF is strictly needed. However, we would 508 like to point out that fault detection can be improved by using 509 receiver side detection (Section 7.4.1) and early reporting of such 510 cases using the ECN feedback mechanism. 512 For interoperability we do mandate the implementation of AVPF, with 513 both RTCP extensions and the necessary signalling to support a common 514 operations mode. This specification will still recommend the usage 515 of AVPF in all cases as negotiation of the common interoperability 516 point requires AVPF, and mixed negotiation of AVP and AVPF depending 517 on other SDP attributes in the same media block are difficult and the 518 fact that fault detection can be improved when using AVPF. The use 519 of the ECN feedback format is also recommended but cases where there 520 is no requirement for timely feedback will be noted. The term "no 521 timely feedback required" will be used to indicate usage that employs 522 this specification in combination with receiver driven congestion 523 control, and initialization methods that do not require timely 524 feedback, i.e. currently leap of faith and ICE based. We also note 525 that any receiver driven congestion control solution that still 526 requires RTCP for signalling of any adaptation information to the 527 sender will still require AVPF. 529 4. Overview of Use of ECN with RTP/UDP/IP 531 The solution for using ECN with RTP over UDP/IP consists of four 532 different pieces that together make the solution work: 534 1. Negotiation of the capability to use ECN with RTP/UDP/IP 536 2. Initiation and initial verification of ECN capable transport 538 3. Ongoing use of ECN within an RTP session 540 4. Handling of dynamic groups through failure detection, 541 verification and fallback 543 The solution includes a new SDP attribute (Section 6.1), the 544 definition of new extensions to RTCP (Section 5) and STUN 545 (Section 7.2.2). 547 Before an RTP session can be created, a signalling protocol is often 548 used to discover the other participants and negotiate session 549 parameters (see Section 7.1). At the minimum a signalling protocol 550 is used to configure RTP session participants through a declarative 551 method. One of the parameters that can be negotiated is the 552 capability of a participant to support ECN functionality, or 553 otherwise. Note that all participants having the capability of 554 supporting ECN does not necessarily imply that ECN is usable in an 555 RTP session, since there may be middleboxes on the path between the 556 participants which don't pass ECN-marked packets (for example, a 557 firewall that blocks traffic with the ECN bits set). This document 558 defines the information that needs to be negotiated, and provides a 559 mapping to SDP for use in both declarative and offer/answer contexts. 561 When a sender joins a session for which all participants claim ECN 562 capability, it must verify if that capability is usable. There are 563 three ways in which this verification may be done (Section 7.2): 565 o The sender may generate a (small) subset of its RTP data packets 566 with the ECN field set to ECT(0) or ECT(1). Each receiver will 567 then send an RTCP feedback packet indicating the reception of the 568 ECT marked RTP packets. Upon reception of this feedback from each 569 receiver it knows of, the sender can consider ECN functional for 570 its traffic. Each sender does this verification independently of 571 each other. If a new receiver joins an existing session it will 572 reveal whether or not it supports ECN when it sends its first RTCP 573 report to each source. If the RTCP report includes ECN 574 information, verification will have succeeded and sources can 575 continue to send ECT packets. If not, verification fails and each 576 sender MUST stop using ECN. 578 o Alternatively, ECN support can be verified during an initial end- 579 to-end STUN exchange (for example, as part of ICE connection 580 establishment). After having verified connectivity without ECN 581 capability an extra STUN exchange, this time with the ECN field 582 set to ECT(0) or ECT(1), is performed. If successful the path's 583 capability to convey ECN marked packets is verified. A new STUN 584 attribute is defined to convey feedback that the ECT marked STUN 585 request was received (see Section 7.2.2), along with an ICE 586 signalling option (Section 6.4). 588 o Thirdly, the sender may make a leap of faith that ECN will work. 589 This is only recommended for applications that know they are 590 running in controlled environments where ECN functionality has 591 been verified through other means. In this mode it is assumed 592 that ECN works, and the system reacts to failure indicators if the 593 assumption proved wrong. The use of this method relies on a high 594 confidence that ECN operation will be successful, or an 595 application where failure is not serious. The impact on the 596 network and other users must be considered when making a leap of 597 faith, so there are limitations on when this method is allowed. 599 The first mechanism, using RTP with RTCP feedback, has the advantage 600 of working for all RTP sessions, but the disadvantages of potential 601 clipping if ECN marked RTP packets are discarded by middleboxes, and 602 slow verification of ECN support. The STUN-based mechanism is faster 603 to verify ECN support, but only works in those scenarios supported by 604 end-to-end STUN, such as within an ICE exchange. The third one, 605 leap-of-faith, has the advantage of avoiding additional tests or 606 complexities and enabling ECN usage from the first media packet. The 607 downside is that if the end-to-end path contains middleboxes that do 608 not pass ECN, the impact on the application can be severe: in the 609 worst case, all media could be lost if a middlebox that discards ECN 610 marked packets is present. A less severe effect, but still requiring 611 reaction, is the presence of a middlebox that re-marks ECT marked 612 packets to non-ECT, possibly marking packets with a CE mark as non- 613 ECT. This can force the network into heavy congestion due to non- 614 responsiveness, and seriously impact media quality. 616 Once ECN support has been verified (or assumed) to work for all 617 receivers, a sender marks all its RTP packets as ECT packets, while 618 receivers rapidly feedback any CE marks to the sender using RTCP in 619 RTP/AVPF immediate or early feedback mode, unless no timely feedback 620 is required. An RTCP feedback report is sent as soon as possible 621 according to the transmission rules for feedback that are in place. 622 This feedback report indicates the receipt of new CE marks since the 623 last ECN feedback packet, and also counts the total number of CE 624 marked packets through a cumulative sum. This is the mechanism to 625 provide the fastest possible feedback to senders about CE marks. On 626 receipt of a CE marked packet, the system must react to congestion 627 as-if packet loss has been reported. Section 7.3 describes the 628 ongoing use of ECN within an RTP session. 630 This rapid feedback is not optimised for reliability, therefore an 631 additional procedure, the RTCP ECN summary reports, is used to ensure 632 more reliable, but less timely, reporting of the ECN information. 633 The ECN summary report contains the same information as the ECN 634 feedback format, only packed differently for better efficiency with 635 reports for many sources. It is sent in a compound RTCP packet, 636 along with regular RTCP reception reports. By using cumulative 637 counters for seen CE, ECT, not-ECT, and packet loss the sender can 638 determine what events have happened since the last report, 639 independently of any RTCP packets having been lost. 641 RTCP traffic MUST NOT be ECT marked for the following reason. ECT 642 marked traffic may be dropped if the path is not ECN compliant. As 643 RTCP is used to provide feedback about what has been transmitted and 644 what ECN markings that are received, it is important that these are 645 received in cases when ECT marked traffic is not getting through. 647 There are numerous reasons why the path the RTP packets take from the 648 sender to the receiver may change, e.g., mobility, link failure 649 followed by re-routing around it. Such an event may result in the 650 packet being sent through a node that is ECN non-compliant, thus re- 651 marking or dropping packets with ECT set. To prevent this from 652 impacting the application for longer than necessary, the operation of 653 ECN is constantly monitored by all senders. Both the RTCP ECN 654 summary reports and the ECN feedback packets allow the sender to 655 compare the number of ECT(0), ECT(1), and non-ECT marked packets 656 received with the number that were sent, while also reporting CE 657 marked and lost packets. If these numbers do not agree, it can be 658 inferred that the path does not reliably pass ECN-marked packets 659 (Section 7.4.2 discusses how to interpret the different cases). A 660 sender detecting a possible ECN non-compliance issue should then stop 661 sending ECT marked packets to determine if that allows the packets to 662 be correctly delivered. If the issues can be connected to ECN, then 663 ECN usage is suspended and possibly also re-negotiated. 665 5. RTCP Extensions for ECN feedback 667 This documents defines two different RTCP extensions: one RTP/AVPF 668 [RFC4585] transport layer feedback format for urgent ECN information, 669 and one RTCP XR [RFC3611] ECN summary report block type for regular 670 reporting of the ECN marking information. The full definition of 671 these extensions usage as part of the complete solution is laid out 672 in Section 7. 674 5.1. RTP/AVPF Transport Layer ECN Feedback packet 676 This RTP/AVPF transport layer feedback format is intended for usage 677 in AVPF early or immediate feedback modes when information needs to 678 urgently reach the sender. Thus its main use is to report on 679 reception of an ECN-CE marked RTP packet so that the sender may 680 perform congestion control, or to speed up the initiation procedures 681 by rapidly reporting that the path can support ECN-marked traffic. 682 The feedback format is also defined with reduced size RTCP [RFC5506] 683 in mind, where RTCP feedback packets may be sent without accompanying 684 Sender or Receiver Reports that would contain the Extended Highest 685 Sequence number and the accumulated number of packet losses. Both 686 are important for ECN to verify functionality and keep track of when 687 CE marking does occur. 689 The RTP/AVPF transport layer feedback packet starts with the common 690 header defined by the RTP/AVPF profile [RFC4585] which is reproduced 691 here for the reader's information: 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 |V=2|P| FMT | PT=RTPFB=205 | length | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | SSRC of packet sender | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | SSRC of media source | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 : Feedback Control Information (FCI) : 703 : : 705 Figure 1: RTP/AVPF Common Packet Format for Feedback Messages 707 From Figure 1 it can be determined the identity of the feedback 708 provider and for which RTP packet sender it applies. Below is the 709 feedback information format defined that is inserted as FCI for this 710 particular feedback messages that is identified with an FMT value = 711 [TBA1]. 713 0 1 2 3 714 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 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 | Extended Highest Sequence Number | Lost packets counter | 717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 718 | CE Counter | not-ECT Counter | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | ECT (0) Counter | ECT (1) Counter | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 Figure 2: ECN Feedback Format 725 The FCI information for the ECN Feedback format (Figure 2) are the 726 following: 728 Extended Highest Sequence Number: The least significant 20-bits from 729 an Extended highest sequence number received value as defined by 730 [RFC3550]. Used to indicate for which packet this report is valid 731 up to. 733 Lost Packets Counter: The cumulative number of RTP packets that the 734 receiver expected to receive from this SSRC, minus the number of 735 packets it actually received. This is the same as the cumulative 736 number of packets lost defined in Section 6.4.1 of [RFC3550] 737 except represented in 12-bit signed format, compared to 24-bit in 738 RTCP SR or RR packets. As with the equivalent value in RTCP SR or 739 RR packets, note that packets that arrive late are not counted as 740 lost, and the loss may be negative if there are duplicates. 742 CE Counter: The cumulative number of RTP packets received from this 743 SSRC since the receiver joined the RTP session that were ECN-CE 744 marked. The receiver should keep track of this value using a 745 local representation that is longer than 16-bits, and only include 746 the 16-bits with least significance. In other words, the field 747 will wrap if more than 65535 packets has been received. 749 ECT(0) Counter: The cumulative number of RTP packets received from 750 this SSRC since the receiver joined the RTP session that had an 751 ECN field value of ECT(0). The receiver should keep track of this 752 value using a local representation that is longer than 16-bits, 753 and only include the 16-bits with least significance. In other 754 words, the field will wrap if more than 65535 packets have been 755 received. 757 ECT(1) Counter: The cumulative number of RTP packets received from 758 this SSRC since the receiver joined the RTP session that had an 759 ECN field value of ECT(1). The receiver should keep track of this 760 value using a local representation that is longer than 16-bits, 761 and only include the 16-bits with least significance. In other 762 words, the field will wrap if more than 65535 packets have been 763 received. 765 not-ECT Counter: The cumulative number of RTP packets received from 766 this SSRC since the receiver joined the RTP session that had an 767 ECN field value of not-ECT. The receiver should keep track of 768 this value using a local representation that is longer than 16- 769 bits, and only include the 16-bits with least significance. In 770 other words, the field will wrap if more than 65535 packets have 771 been received. 773 Each FCI block reports on a single source (SSRC). Multiple sources 774 can be reported by including multiple RTCP feedback messages in an 775 compound RTCP packet. The AVPF common header indicates both the 776 sender of the feedback message and on which stream it relates to. 778 The counters SHALL be initiated to 0 for a new receiver. This to 779 enable detection of CE or Packet loss already on the initial report 780 from a specific participant. 782 The Extended Highest sequence number and packet loss fields are both 783 truncated in comparison to the RTCP SR or RR versions. This is to 784 save bits as the representation is redundant unless reduced size RTCP 785 is used in such a way that only feedback packets are transmitted, 786 with no SR or RR in the compound RTCP packet. Due to that fact 787 regular RTCP reporting will include the longer versions of the fields 788 and there will be less of an issue with wrapping unless the packet 789 rate of the application is so high that the fields will wrap within a 790 regular RTCP reporting interval. In that case the feedback packet 791 will need to be sent in a compound packet together with the SR or RR 792 packet. 794 There is an issue with packet duplication in relation to the packet 795 loss counter. If one avoids holding state for which sequence number 796 has been received then the way one can count loss is to count the 797 number of received packets and compare that to the number of packets 798 expected. As a result a packet duplication can hide a packet loss. 799 If a receiver is tracking the sequence numbers actually received and 800 suppresses duplicates it provides for a more reliable packet loss 801 indication. Reordering may also result in that packet loss is 802 reported in one report and then removed in the next. 804 The CE counter is actually more robust for packet duplication. 805 Adding each received CE marked packet to the counter is not an issue. 806 If one of the clones was CE marked that is still a indication of 807 congestion. Packet duplication has potential impact on the ECN 808 verification. Thus the sum of packets reported may be higher than 809 the number sent. However, most detections are still applicable. 811 5.2. RTCP XR Report block for ECN summary information 813 This unilateral XR report block combined with RTCP SR or RR report 814 blocks carries the same information as the ECN Feedback Packet and 815 shall be based on the same underlying information. However, there is 816 a difference in semantics between the feedback format and this XR 817 version. Where the feedback format is intended to report on a CE 818 mark as soon as possible, this extended report is for the regular 819 RTCP report and continuous verification of the ECN functionality end- 820 to-end. 822 The ECN Summary report block consists of one report block header: 823 0 1 2 3 824 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 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | BT | Reserved | Block Length | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 and then followed of one or more of the following report data blocks: 831 0 1 2 3 832 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 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 | SSRC of Media Sender | 835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 836 | CE Counter | not-ECT Counter | 837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 | ECT (0) Counter | ECT (1) Counter | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 BT: Block Type identifying the ECN summary report block. Value is 842 [TBA2]. 844 Reserved: All bits SHALL be set to 0 on transmission and ignored on 845 reception. 847 Block Length: The length of the report block. Used to indicate the 848 number of report data blocks present in the ECN summary report. 849 This length will be 3*n, where n is the number of ECN summary 850 report blocks, since blocks are a fixed size. 852 SSRC of Media Sender: The SSRC identifying the media sender this 853 report is for. 855 CE Counter: as in Section 5.1. 857 ECT(0) Counter: as in Section 5.1. 859 ECT(1) Counter: as in Section 5.1. 861 not-ECT Counter: as in Section 5.1. 863 The Extended Highest Sequence number and the packet loss counter for 864 each SSRC is not present in RTCP XR report, in contrast to the 865 feedback version. The reason is that this summary report will rely 866 on the information sent in the Sender Report (SR) or Receiver Report 867 (RR) blocks part of the same RTCP compound packet. The information 868 available in SR or RR are the Extended Highest Sequence number and 869 the accumulated number of packet losses. 871 All the SSRCs that are present in the SR or RR SHALL also be included 872 in the RTCP XR ECN summary report. In cases where the number of 873 senders are so large that the combination of SR/RR and the ECN 874 summary for all the senders exceed the MTU, then only a subset of the 875 senders SHOULD be included so that the reports for the subset fits 876 within the MTU. The subsets SHOULD be selected round-robin across 877 multiple intervals so that all sources are reported. 879 6. SDP Signalling Extensions for ECN 881 This section defines a number of SDP signalling extensions used in 882 the negotiation of the ECN for RTP support when using SDP. This 883 include one SDP attribute "ecn-capable-rtp" that negotiates the 884 actual operation of ECN for RTP. Two SDP signalling parameters are 885 defined to indicate the usage of the RTCP XR ECN summary block and 886 the AVPF feedback format for ECN. One ICE option SDP reprensenation 887 is also defined. 889 6.1. Signalling ECN Capability using SDP 891 One new SDP attribute, "a=ecn-capable-rtp", is defined. This is a 892 media level attribute, thus it is normally included as part of the 893 media description, but if present at session level the same 894 configuration applies to all media descriptions. It is not subject 895 to the character set chosen. The aim of this signalling is to 896 indicate the capability of the sender and receivers to support ECN, 897 and to negotiate the method of ECN initiation to be used in the 898 session. The attribute takes a list of initiation methods, ordered 899 in decreasing preference. The defined values for the initiation 900 method are: 902 rtp: Using RTP and RTCP as defined in Section 7.2.1. 904 ice: Using STUN within ICE as defined in Section 7.2.2. 906 leap: Using the leap of faith method as defined in Section 7.2.3. 908 Further methods may be specified in the future, so unknown methods 909 MUST be ignored upon reception. 911 In addition, a number of OPTIONAL parameters may be included in the 912 "a=ecn-capable-rtp" attribute as follows: 914 mode: This parameter signals the endpoint's capability to set and 915 read ECN marks in UDP packets. An examination of various 916 operating systems has shown that end-system support for ECN 917 marking of UDP packets may be symmetric or asymmetric. By this we 918 mean that some systems may allow end points to set the ECN bits in 919 an outgoing UDP packet but not read them, while others may allow 920 applications to read the ECN bits but not set them. This 921 either/or case may produce an asymmetric support for ECN and thus 922 should be conveyed in the SDP signalling. The "mode=setread" 923 state is the ideal condition where an endpoint can both set and 924 read ECN bits in UDP packets. The "mode=setonly" state indicates 925 that an endpoint can set the ECT bit, but cannot read the ECN bits 926 from received UDP packets to determine if upstream congestion 927 occurred. The "mode=readonly" state indicates that the endpoint 928 can read the ECN bits to determine if congestion has occurred for 929 incomming packet, but it cannot set the ECT bits in outgoing UDP 930 packets. When the "mode=" parameter is omitted it is assumed that 931 the node has "setread" capabilities. This option can provide for 932 an early indication that ECN cannot be used in a session. This 933 would be case when both the offerer and answerer set the "mode=" 934 parameter to "setonly" or "readonly", or when an RTP sender entity 935 considers offering "readonly". 937 ect: This parameter makes it possible to express the preferred ECT 938 marking. This is either "random", "0", or "1", with "0" being 939 implied if not specified. The "ect" parameter describes a 940 receiver preference, and is useful in the case where the receiver 941 knows it is behind a link using IP header compression, the 942 efficiency of which would be seriously disrupted if it were to 943 receive packets with randomly chosen ECT marks. It is RECOMMENDED 944 that ECT(0) marking be used. 946 The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp" attribute is 947 as follows: 949 ecn-attribute = "a=ecn-capable-rtp:" SP init-list [SP parm-list] 950 init-list = init-value *("," init-value) 951 init-value = "rtp" / "ice" / "leap" / init-ext 952 init-ext = token 953 parm-list = parm-value *(";" SP parm-value) 954 parm-value = mode / ect / parm-ext 955 mode = "mode=" ("setonly" / "setread" / "readonly") 956 ect = "ect=" ("0" / "1" / "random") 957 parm-ext = parm-name "=" parm-value-ext 958 parm-name = token 959 parm-value-ext = token / quoted-string 960 quoted-string = DQUOTE *qdtext DQUOTE 961 qdtext = %x20-21 / %x23-7E / %x80-FF 962 ; any 8-bit ascii except <"> 964 ; external references: 965 ; token: from RFC 4566 966 ; SP and DQUOTE from RFC 5234 968 When SDP is used with the offer/answer model [RFC3264], the party 969 generating the SDP offer MUST insert an "a=ecn-capable-rtp" attribute 970 into the media section of the SDP offer of each RTP flow for which it 971 wishes to use ECN. The attribute includes one or more ECN initiation 972 methods in a comma separated list in decreasing order of preference, 973 with any number of optional parameters following. The answering 974 party compares the list of initiation methods in the offer with those 975 it supports in order of preference. If there is a match, and if the 976 receiver wishes to attempt to use ECN in the session, it includes an 977 "a=ecn-capable-rtp" attribute containing its single preferred choice 978 of initiation method in the media sections of the answer. If there 979 is no matching initiation method capability, or if the receiver does 980 not wish to attempt to use ECN in the session, it does not include an 981 "a=ecn-capable-rtp" attribute in its answer. If the attribute is 982 removed in the answer then ECN MUST NOT be used in any direction for 983 that media flow. If there are initilization methods that are 984 unknown, they MUST be ignored on reception and MUST NOT be included 985 in an answer. The answer may also include optional parameters, as 986 discussed below. 988 If the "mode=setonly" parameter is present in the "a=ecn-capable-rtp" 989 attribute of the offer and the answering party is also 990 "mode=setonly", then there is no common ECN capability, and the 991 answer MUST NOT include the "a=ecn-capable-rtp" attribute. 992 Otherwise, if the offer is "mode=setonly" then ECN may only be 993 initiated in the direction from the offering party to the answering 994 party. 996 If the "mode=readonly" parameter is present in the "a=ecn-capable- 997 rtp" attribute of the offer and the answering party is 998 "mode=readonly", then there is no common ECN capability, and the 999 answer MUST NOT include the "a=ecn-capable-rtp" attribute. 1000 Otherwise, if the offer is "mode=readonly" then ECN may only be 1001 initiated in the direction from the answering party to the offering 1002 party. 1004 If the "mode=setread" parameter is present in the "a=ecn-capable-rtp" 1005 attribute of the offer and the answering party is "setonly", then ECN 1006 may only be initiated in the direction from the answering party to 1007 the offering party. If the offering party is "mode=setread" but the 1008 answering party is "mode=readonly", then ECN may only be initiated in 1009 the direction from the offering party to the answering party. If 1010 both offer and answer are "mode=setread", then ECN may be initiated 1011 in both directions. Note that "mode=setread" is implied by the 1012 absence of a "mode=" parameter in the offer or the answer. 1014 In an RTP session using multicast all participants intending to send 1015 RTP packets needs support setting ECT in the RTP packets, and all 1016 participants receiving needs to have the capability to read ECN 1017 values on incoming packets. Especially the later is important, 1018 otherwise no sender in the multicast session will be able to enable 1019 ECN. If a session is negotiated using offer/answer it is preferable 1020 that intended session participant would be aware of the signalling 1021 attributes and if not capable but ECN for RTP aware SHOULD refuse to 1022 join the session. For intended session participants that are not 1023 aware of the ECN for RTP signalling and simple ignore the signalling 1024 attribute the other party in the offer/answer exchange SHOULD 1025 terminate the SIP dialog so that the participant leaves the session. 1027 The "ect=" parameter in the "a=ecn-capable-rtp" attribute is set 1028 independently in the offer and the answer. Its value in the offer 1029 indicates a preference for the sending behaviour of the answering 1030 party, and its value in the answer indicates a sending preference for 1031 the behaviour of the offering party. It will be the senders choice 1032 to honour the receivers preference for what to receive or not. In 1033 multicast sessions, any sender SHOULD send using the value declared 1034 in the ect parameter. 1036 Unknown optional parameters MUST be ignored on reception, and MUST 1037 NOT be included in the answer. That way new parameters may be 1038 introduced and verified to be supported by the other end-point by 1039 having them include it in any answer. 1041 When SDP is used in a declarative manner, for example in a multicast 1042 session using the Session Announcement Protocol (SAP, [RFC2974]), 1043 negotiation of session description parameters is not possible. The 1044 "a=ecn-capable-rtp" attribute MAY be added to the session description 1045 to indicate that the sender will use ECN in the RTP session. The 1046 attribute MUST include a single method of initiation. Participants 1047 MUST NOT join such a session unless they have the capability to 1048 receive ECN-marked UDP packets, implement the method of initiation, 1049 and can generate RTCP ECN feedback (note that having the capability 1050 to use ECN doesn't necessarily imply that the underlying network path 1051 between sender and receiver supports ECN). The mode parameter MAY be 1052 included also in declarative usage, to indicate the minimal 1053 capability is required by the consumer of the SDP. So for example in 1054 a SSM session the participants configured with a particular SDP will 1055 all be in a media receive only mode, thus mode=readonly will work as 1056 the capability of reporting on the ECN markings in the received is 1057 what is required. However, using "mode=readonly" also in ASM 1058 sessions is reasonable, unless all senders are required to attempt to 1059 use ECN for their outgoing RTP data traffic, in which case the mode 1060 needs to be set to "setread". 1062 The "a=ecn-capable-rtp" attribute MAY be used with RTP media sessions 1063 using UDP/IP transport. It MUST NOT be used for RTP sessions using 1064 TCP, SCTP, or DCCP transport, or for non-RTP sessions. 1066 As described in Section 7.3.3, RTP sessions using ECN require rapid 1067 RTCP ECN feedback, unless timely feedback is not required due to a 1068 receiver driven congestion control. To ensure that the sender can 1069 react to ECN-CE marked packets timely feedback is usually required. 1070 Thus, the use of the Extended RTP Profile for RTCP-Based Feedback 1071 (RTP/AVPF) [RFC4585] or other profile that inherits AVPF's signalling 1072 rules, MUST be signalled unless timely feedback is not required. If 1073 timely feedback is not required it is still RECOMMENDED to used AVPF. 1074 The signalling of an AVPF based profile is likely to be required even 1075 if the preferred method of initialization and the congestion control 1076 does not require timely feedback, as the common interoperable method 1077 is likely to be signalled or the improved fault reaction is desired. 1079 6.2. RTCP Feedback SDP Parameter 1081 A new "nack" feedback parameter "ecn" is defined to indicate the 1082 usage of the RTCP ECN feedback packet format (Section 5.1). The ABNF 1083 [RFC5234] definition of the SDP parameter extension is: 1085 rtcp-fb-nack-param = 1086 rtcp-fb-nack-param /= ecn-fb-par 1087 ecn-fb-par = SP "ecn" 1089 The offer/answer rules for this SDP feedback parameters are specified 1090 in AVPF [RFC4585]. 1092 6.3. XR Block SDP Parameter 1094 A new unilateral RTCP XR block for ECN summary information is 1095 specified, thus the XR block SDP signalling also needs to be extended 1096 with a parameter. This is done in the same way as for the other XR 1097 blocks. The XR block SDP attribute as defined in Section 5.1 of the 1098 RTCP XR specification [RFC3611] is defined to be extendible. As no 1099 parameter values are needed for this ECN summary block, this 1100 parameter extension consistis of a simple parameter name used to 1101 indicate support and intent to use the XR block. 1103 xr-format = 1104 xr-format /= ecn-summary-par 1105 ecn-summary-par = "ecn-sum" 1107 For SDP declarative and offer/answer usage, see the RTCP XR 1108 specification[RFC3611] and its specifciation of how to handle 1109 unilateral parameters. 1111 6.4. ICE Parameter to Signal ECN Capability 1113 One new ICE [RFC5245] option, "rtp+ecn", is defined. This is used 1114 with the SDP session level "a=ice-options" attribute in an SDP offer 1115 to indicate that the initiator of the ICE exchange has the capability 1116 to support ECN for RTP-over-UDP flows (via "a=ice-options: rtp+ecn"). 1117 The answering party includes this same attribute at the session level 1118 in the SDP answer if it also has the capability, and removes the 1119 attribute if it does not wish to use ECN, or doesn't have the 1120 capability to use ECN. If the ICE initiation method (Section 7.2.2) 1121 actually is going to be used, it is also needs to be explicitly 1122 negotiated using the "a=ecn-capable-rtp" attribute. This ICE option 1123 SHALL be included when the ICE initiation method is offered or 1124 declared in the SDP. 1126 Note: This signalling mechanism is not strictly needed as long as 1127 the STUN ECN testing capability is used within the context of this 1128 document. It may however be useful if the ECN verification 1129 capability is used in additional contexts. 1131 7. Use of ECN with RTP/UDP/IP 1133 In the detailed specification of the behaviour below, the different 1134 functions in the general case will first be discussed. In case 1135 special considerations are needed for middleboxes, multicast usage 1136 etc, those will be specially discussed in related subsections. 1138 7.1. Negotiation of ECN Capability 1140 The first stage of ECN negotiation for RTP-over-UDP is to signal the 1141 capability to use ECN. This includes negotiating if ECN is to be 1142 used symmetrically and the method for initial ECT verification. This 1143 memo defines the mappings of this information onto SDP for both 1144 declarative and offer/answer usage. There is one SDP extension to 1145 indicate if ECN support should be used, and the method for initiation 1146 (Section 6.1). Further parameters to indicate support for the AVPF 1147 ECN feedback format (Section 6.2) and the ECN XR summary report 1148 (Section 6.3). In addition an ICE parameter is defined (Section 6.4) 1149 to indicate that ECN initiation using STUN is supported as part of an 1150 ICE exchange. 1152 An RTP system that supports ECN and uses SDP in the signalling MUST 1153 implement the SDP extension to signal ECN capability as described in 1154 Section 6.1, the ECN feedback SDP parameter Section 6.2, and the ECN 1155 XR SDP parameter Section 6.3. It MAY also implement alternative ECN 1156 capability negotiation schemes, such as the ICE extension described 1157 in Section 6.4. 1159 The "ecn-capable-rtp" SDP attribute MUST always be used when 1160 employing ECN for RTP according to this specification. As the XR ECN 1161 summary report is required independently of the initialization 1162 method, or congestion control scheme the "rtcp-xr" attribute with the 1163 "ecn-sum" parameter MUST also be used. The "rtcp-fb" attribute with 1164 the "nack" parameter "ecn" MUST be used whenever the initialization 1165 method or a congestion control algorithm requiring timely sender side 1166 knowledge of received CE markings. If the congestion control scheme 1167 uses additional signalling they should be indicated as appropriate 1168 for those signalling methods. 1170 7.2. Initiation of ECN Use in an RTP Session 1172 Once the sender and the receiver(s) have agreed that they have the 1173 capability to use ECN within a session, they may attempt to initiate 1174 ECN use. 1176 At the start of the RTP session, when the first packets with ECT are 1177 sent, it is important to verify that IP packets with ECN field values 1178 of ECT or ECN-CE will reach their destination(s). There is some risk 1179 that the use of ECN will result in either reset of the ECN field, or 1180 loss of all packets with ECT or ECN-CE markings. If the path between 1181 the sender and the receivers exhibits either of these behaviours one 1182 needs to stop using ECN immediately to protect both the network and 1183 the application. 1185 The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic 1186 at any time. This is to ensure that packet loss due to ECN marking 1187 will not effect the RTCP traffic and the necessary feedback 1188 information it carries. 1190 An RTP system that supports ECN MUST implement the initiation of ECN 1191 using in-band RTP and RTCP described in Section 7.2.1. It MAY also 1192 implement other mechanisms to initiate ECN support, for example the 1193 STUN-based mechanism described in Section 7.2.2 or use the leap of 1194 faith option if the session supports the limitations provided in 1195 Section 7.2.3. If support for both in-band and out-of-band 1196 mechanisms is signalled, the sender should try ECN negotiation using 1197 STUN with ICE first, and if it fails, fallback to negotiation using 1198 RTP and RTCP ECN feedback. 1200 No matter how ECN usage is initiated, the sender MUST continually 1201 monitor the ability of the network, and all its receivers, to support 1202 ECN, following the mechanisms described in Section 7.4. This is 1203 necessary because path changes or changes in the receiver population 1204 may invalidate the ability of the system to use ECN. 1206 7.2.1. Detection of ECT using RTP and RTCP 1208 The ECN initiation phase using RTP and RTCP to detect if the network 1209 path supports ECN comprises three stages. Firstly, the RTP sender 1210 generates some small fraction of its traffic with ECT marks to act a 1211 probe for ECN support. Then, on receipt of these ECT-marked packets, 1212 the receivers send RTCP ECN feedback packets and RTCP ECN summary 1213 reports to inform the sender that their path supports ECN. Finally, 1214 the RTP sender makes the decision to use ECN or not, based on whether 1215 the paths to all RTP receivers have been verified to support ECN. 1217 Generating ECN Probe Packets: During the ECN initiation phase, an 1218 RTP sender SHALL mark a small fraction of its RTP traffic as ECT, 1219 while leaving the reminder of the packets unmarked. The main 1220 reason for only marking some packets is to maintain usable media 1221 delivery during the ECN initiation phase in those cases where ECN 1222 is not supported by the network path. A secondary reason to send 1223 some not-ECT packets are to ensure that the receivers will send 1224 RTCP reports on this sender, even if all ECT marked packets are 1225 lost in transit. The not-ECT packets also provide a base-line to 1226 compare performance parameters against. A fourth reason for only 1227 probing with a small number of packets is to reduce the risk that 1228 significant numbers of congestion markings might be lost if ECT is 1229 cleared to Not-ECT by an ECN-Reverting Meddlebox. Then any 1230 resulting lack of congestion response is likely to have little 1231 damaging affect on others. An RTP sender is RECOMMENDED to send a 1232 minimum of two packets with ECT markings per RTCP reporting 1233 interval. In case an random ECT pattern is intended to be used, 1234 at least one with ECT(0) and one with ECT(1) per reporting 1235 interval, in case a single ECT marking is to be used, only that 1236 ECT value SHOULD be sent. The RTP sender will continue to send 1237 some ECT marked traffic as long as the ECN initiation phase 1238 continues. The sender SHOULD NOT mark all RTP packets as ECT 1239 during the ECN initiation phase. 1241 This memo does not mandate which RTP packets are marked with ECT 1242 during the ECN initiation phase. An implementation should insert 1243 ECT marks in RTP packets in a way that minimises the impact on 1244 media quality if those packets are lost. The choice of packets to 1245 mark is clearly very media dependent, but the usage of RTP NO-OP 1246 payloads [I-D.ietf-avt-rtp-no-op], if supported, would be an 1247 appropriate choice. For audio formats, if would make sense for 1248 the sender to mark comfort noise packets or similar. For video 1249 formats, packets containing P- or B-frames, rather than I-frames, 1250 would be an appropriate choice. No matter which RTP packets are 1251 marked, those packets MUST NOT be sent in duplicate with and 1252 without ECT, since their RTP sequence number is used to identify 1253 packets that are received with ECN markings. 1255 Generating RTCP ECN Feedback: If ECN capability has been negotiated 1256 in an RTP session, the receivers in the session MUST listen for 1257 ECT or ECN-CE marked RTP packets, and generate RTCP ECN feedback 1258 packets (Section 5.1) to mark their receipt. An immediate or 1259 early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD 1260 be generated on receipt of the first ECT or ECN-CE marked packet 1261 from a sender that has not previously sent any ECT traffic. Each 1262 regular RTCP report MUST also contain an ECN summary report 1263 (Section 5.2). Reception of subsequent ECN-CE marked packets MUST 1264 result in additional early or immediate ECN feedback packets being 1265 sent unless no timely feedback is required. 1267 Determination of ECN Support: RTP is a group communication protocol, 1268 where members can join and leave the group at any time. This 1269 complicates the ECN initiation phase, since the sender must wait 1270 until it believes the group membership has stabilised before it 1271 can determine if the paths to all receivers support ECN (group 1272 membership changes after the ECN initiation phase has completed 1273 are discussed in Section 7.3). 1275 An RTP sender shall consider the group membership to be stable 1276 after it has been in the session and sending ECT-marked probe 1277 packets for at least three RTCP reporting intervals (i.e., after 1278 sending its third regularly scheduled RTCP packet), and when a 1279 complete RTCP reporting interval has passed without changes to the 1280 group membership. ECN initiation is considered successful when 1281 the group membership is stable, and all known participants have 1282 sent one or more RTCP ECN feedback packets indicating correct 1283 receipt of the ECT-marked RTP packets generated by the sender. 1285 As an optimisation, if an RTP sender is initiating ECN usage 1286 towards a unicast address, then it MAY treat the ECN initiation as 1287 provisionally successful if it receives a single RTCP ECN feedback 1288 report indicating successful receipt of the ECT-marked packets, 1289 with no negative indications, from a single RTP receiver. After 1290 declaring provisional success, the sender MAY generate ECT-marked 1291 packets as described in Section 7.3, provided it continues to 1292 monitor the RTCP reports for a period of three RTCP reporting 1293 intervals from the time the ECN initiation started, to check if 1294 there is any other participants in the session. If other 1295 participants are detected, the sender MUST fallback to only ECT- 1296 marking a small fraction of its RTP packets, while it determines 1297 if ECN can be supported following the full procedure described 1298 above. 1300 Note: One use case that requires further consideration is a 1301 unicast connection with several SSRCs multiplexed onto the same 1302 flow (e.g., an SVC video using SSRC multiplexing for the 1303 layers). It is desirable to be able to rapidly negotiate ECN 1304 support for such a session, but the optimisation above fails 1305 since the multiple SSRCs make it appear that this is a group 1306 communication scenario. It's not sufficient to check that all 1307 SSRCs map to a common RTCP CNAME to check if they're actually 1308 located on the same device, because there are implementations 1309 that use the same CNAME for different parts of a distributed 1310 implementation. 1312 ECN initiation is considered to have failed at the instant when 1313 any RTP session participant sends an RTCP packet that doesn't 1314 contain an RTCP ECN feedback report or ECN summary report, but has 1315 an RTCP RR with an extended RTP sequence number field that 1316 indicates that it should have received multiple (>3) ECT marked 1317 RTP packets. This can be due to failure to support the ECN 1318 feedback format by the receiver or some middlebox, or the loss of 1319 all ECT marked packets. Both indicate a lack of ECN support. 1321 If the ECN negotiation succeeds, this indicates that the path can 1322 pass some ECN-marked traffic, and that the receivers support ECN 1323 feedback. This does not necessarily imply that the path can robustly 1324 convey ECN feedback; Section 7.3 describes the ongoing monitoring 1325 that must be performed to ensure the path continues to robustly 1326 support ECN. 1328 When a sender or receiver detects ECN failures on paths they should 1329 log these to enable follow up and statistics gathering regarding 1330 broken paths. The logging mechanism used is implementation 1331 dependent. 1333 7.2.2. Detection of ECT using STUN with ICE 1335 This section describes an OPTIONAL method that can be used to avoid 1336 media impact and also ensure an ECN capable path prior to media 1337 transmission. This method is considered in the context where the 1338 session participants are using ICE [RFC5245] to find working 1339 connectivity. We need to use ICE rather than STUN only, as the 1340 verification needs to happen from the media sender to the address and 1341 port on which the receiver is listening. 1343 To minimise the impact of set-up delay, and to prioritise the fact 1344 that one has a working connectivity rather than necessarily finding 1345 the best ECN capable network path, this procedure is applied after 1346 having performed a successful connectivity check for a candidate, 1347 which is nominated for usage. At that point, and provided the chosen 1348 candidate is not a relayed address, an additional connectivity check 1349 is performed, sending the "ECT Check" attribute in a STUN packet that 1350 is ECT marked. On reception of the packet, a STUN server supporting 1351 this extension will note the received ECN field value, and send a 1352 STUN/UDP/IP packet in reply, with the ECN field set to not-ECT, and 1353 including an ECN check attribute. A STUN server that doesn't 1354 understand the extension or is incapable of reading the ECN values on 1355 incoming STUN packets should follow the STUN specifications rule for 1356 unknown comprehension-optional attributes, i.e. ignore the attribute. 1357 Which will result in the sender receiving a STUN response but without 1358 the ECN Check STUN attribute. 1360 The STUN ECN check attribute contains one field and a flag. The flag 1361 indicates whether the echo field contains a valid value or not. The 1362 field is the ECN echo field, and when valid contains the two ECN bits 1363 from the packet it echoes back. The ECN check attribute is a 1364 comprehension optional attribute. 1366 0 1 2 3 1367 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 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | Type | Length | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | Reserved |ECF|V| 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1374 Figure 3: ECN Check STUN Attribute 1376 V: Valid (1 bit) ECN Echo value field is valid when set to 1, and 1377 invalid when set 0. 1379 ECF: ECN Echo value field (2 bits) contains the ECN field value of 1380 the STUN packet it echoes back when field is valid. If invalid 1381 the content is arbitrary. 1383 Reserved: Reserved bits (29 bits) SHALL be set to 0 on transmission, 1384 and SHALL be ignored on reception. 1386 This attribute MAY be included in any STUN request to request the ECN 1387 field to be echoed back. In STUN requests the V bit SHALL be set to 1388 0. A compliant STUN server receiving a request with the ECN Check 1389 attribute SHALL read the ECN field value of the IP/UDP packet the 1390 request was received in. Upon forming the response the server SHALL 1391 include the ECN Check attribute setting the V bit to valid and 1392 include the read value of the ECN field into the ECF field. If the 1393 STUN responder was unable to ascertain, due to temporary errors, the 1394 ECN value of the STUN request, it SHALL set the V bit in the response 1395 to 0. The STUN client may retry immediately. 1397 7.2.3. Leap of Faith ECT initiation method 1399 This method for initiating ECN usage is a leap of faith that assumes 1400 that ECN will work on the used path(s). The method is to go directly 1401 to "ongoing use of ECN" as defined in Section 7.3. Thus all RTP 1402 packets MAY be marked as ECT and the failure detection MUST be used 1403 to detect any case when the assumption that the path was ECT capable 1404 is wrong. This method is only recommended for controlled 1405 environments where the whole path(s) between sender and receiver(s) 1406 has been built and verified to be ECT. 1408 If the sender marks all packets as ECT while transmitting on a path 1409 that contains an ECN-blocking middlebox, then receivers downstream of 1410 that middlebox will not receive any RTP data packets from the sender, 1411 and hence will not consider it to be an active RTP SSRC. The sender 1412 can detect this and revert to sending packets without ECT marks, 1413 since RTCP SR/RR packets from such receivers will either not include 1414 a report for sender's SSRC, or will report that no packets have been 1415 received, but this takes at least one RTCP reporting interval. It 1416 should be noted that a receiver might generate its first RTCP packet 1417 immediately on joining a unicast session, or very shortly after 1418 joining a RTP/AVPF session, before it has had chance to receive any 1419 data packets. A sender that receives RTCP SR/RR packet indicating 1420 lack of reception by a receiver SHOULD therefore wait for a second 1421 RTCP report from that receiver to be sure that the lack of reception 1422 is due to ECT-marking. Since this recovery process can take several 1423 tens of seconds, during which time the RTP session is unusable for 1424 media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation 1425 method be used in environments where ECN-blocking middleboxes are 1426 likely to be present. 1428 7.3. Ongoing Use of ECN Within an RTP Session 1430 Once ECN usage has been successfully initiated for an RTP sender, 1431 that sender begins sending all RTP data packets as ECT-marked, and 1432 its receivers continue sending ECN feedback information via RTCP 1433 packets. This section describes procedures for sending ECT-marked 1434 data, providing ECN feedback information via RTCP, responding to ECN 1435 feedback information, and detecting failures and misbehaving 1436 receivers. 1438 7.3.1. Transmission of ECT-marked RTP Packets 1440 After a sender has successfully initiated ECN usage, it SHOULD mark 1441 all the RTP data packets it sends as ECT. The sender SHOULD mark 1442 packets as ECT(0) unless the receiver expresses a preference for 1443 ECT(1) or random using the "ect" parameter in the "a=ecn-capable-rtp" 1444 attribute. 1446 The sender SHALL NOT include ECT marks on outgoing RTCP packets, and 1447 SHOULD NOT include ECT marks on any other outgoing control messages 1448 (e.g. STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or 1449 ZRTP [I-D.zimmermann-avt-zrtp] control packets) that are multiplexed 1450 on the same UDP port. For control packets there might be exceptions, 1451 like the STUN based ECN check defined in Section 7.2.2. 1453 7.3.2. Reporting ECN Feedback via RTCP 1455 An RTP receiver that receives a packet with an ECN-CE mark, or that 1456 detects a packet loss, MUST schedule the transmission of an RTCP ECN 1457 feedback packet as soon as possible (subject to the constraints of 1458 [RFC4585] and [RFC3550]) to report this back to the sender unless no 1459 timely feedback required. There should be no difference in behavior 1460 if ECN-CE marks or packet drops are detected. The feedback RTCP 1461 packet sent SHALL consist of at least one ECN feedback packet 1462 (Section 5) reporting on the packets received since the last ECN 1463 feedback packet, and SHOULD contain an RTCP SR or RR packet. The 1464 RTP/AVPF profile in early or immediate feedback mode SHOULD be used 1465 where possible, to reduce the interval before feedback can be sent. 1466 To reduce the size of the feedback message, reduced size RTCP 1467 [RFC5506] MAY be used if supported by the end-points. Both RTP/AVPF 1468 and reduced size RTCP MUST be negotiated in the session set-up 1469 signalling before they can be used. 1471 Every time a regular compound RTCP packet is to be transmitted, an 1472 ECN-capable RTP receiver MUST include an RTCP XR ECN summary report 1473 as described in Section 5.2 as part of the compound packet. 1475 The multicast feedback implosion problem, that occurs when many 1476 receivers simultaneously send feedback to a single sender, must also 1477 be considered. The RTP/AVPF transmission rules will limit the amount 1478 of feedback that can be sent, avoiding the implosion problem but also 1479 delaying feedback by varying degrees from nothing up to a full RTCP 1480 reporting interval. As a result, the full extent of a congestion 1481 situation may take some time to reach the sender, although some 1482 feedback should arrive in a reasonably timely manner, allowing the 1483 sender to react on a single or a few reports. 1485 A possible future optimisation might be to define some form of 1486 feedback suppression mechanism to reduce the RTCP reporting 1487 overhead for group communication using ECN. 1489 7.3.3. Response to Congestion Notifications 1491 The reception of RTP packets with ECN-CE marks in the IP header are a 1492 notification that congestion is being experience. The default 1493 reaction on the reception of these ECN-CE marked packets MUST be to 1494 provide the congestion control algorithm with notification and that 1495 it is treated as a packet loss would when it comes to indicating 1496 congestion. 1498 We note that there MAY be other reactions to ECN-CE specified in the 1499 future. Such an alternative reaction MUST be specified and 1500 considered to be safe for deployment under any restrictions 1501 specified. A potential example for an alternative reaction could be 1502 emergency communications (such as that generated by first responders, 1503 as opposed to the general public) in networks where the user has been 1504 authorized. A more detailed description of these other reactions, as 1505 well as the types of congestion control algorithms used by end-nodes, 1506 is outside of the scope of this document. 1508 Depending on the media format, type of session, and RTP topology 1509 used, there are several different types of congestion control that 1510 can be used. 1512 Sender-Driven Congestion Control: The sender may be responsible for 1513 adapting the transmitted bit-rate in response to RTCP ECN 1514 feedback. When the sender receives the ECN feedback data it feeds 1515 this information into its congestion control or bit-rate 1516 adaptation mechanism so that it can react on it as if it was 1517 packet losses that was reported. The congestion control algorithm 1518 to be used is not specified here, although TFRC [RFC5348] is one 1519 example that might be used. 1521 Receiver-Driven Congestion Control: If a receiver driven congestion 1522 control mechanism is used, the receiver can react to the ECN-CE 1523 marks without contacting the sender. This may allow faster 1524 response than sender-driven congestion control in some 1525 circumstances. Receiver-driven congestion control is usually 1526 implemented by providing the content in a layered way, with each 1527 layer providing improved media quality but also increased 1528 bandwidth usage. The receiver locally monitors the ECN-CE marks 1529 on received packet to check if it experiences congestion at the 1530 current number of layers. If congestion is experienced, the 1531 receiver drops one layer, so reducing the resource consumption on 1532 the path towards itself. For example, if a layered media encoding 1533 scheme such as H.264 SVC is used, the receiver may change its 1534 layer subscription, and so reduce the bit rate it receives. The 1535 receiver MUST still send RTCP XR ECN Summary to the sender, even 1536 if it can adapt without contact with the sender, so that the 1537 sender can determine if ECN is supported on the network path. The 1538 timeliness of RTCP feedback is less of a concern with receiver 1539 driven congestion control, and regular RTCP reporting of ECN 1540 summary information is sufficient (without using RTP/AVPF 1541 immediate or early feedback). 1543 Hybrid: There might be mechanisms that utilize both some receiver 1544 behaviors and some sender side monitoring, thus requiring both 1545 feedback of congestion events to the sender and taking receiver 1546 decisions and possible signalling to the sender. From this 1547 solution the congestion control algorithm needs to use the 1548 signalling to indicate which functions of ECN that is needed to be 1549 used. 1551 Responding to congestion indication in the case of multicast traffic 1552 is a more complex problem than for unicast traffic. The fundamental 1553 problem is diverse paths, i.e. when different receivers don't see the 1554 same path, and thus have different bottlenecks, so the receivers may 1555 get ECN-CE marked packets due to congestion at different points in 1556 the network. This is problematic for sender driven congestion 1557 control, since when receivers are heterogeneous in regards to 1558 capacity the sender is limited to transmitting at the rate the 1559 slowest receiver can support. This often becomes a significant 1560 limitation as group size grows. Also, as group size increases the 1561 frequency of reports from each receiver decreases, which further 1562 reduces the responsiveness of the mechanism. Receiver-driven 1563 congestion control has the advantage that each receiver can choose 1564 the appropriate rate for its network path, rather than all having to 1565 settle for the lowest common rate. 1567 We note that ECN support is not a silver bullet to improving 1568 performance. The use of ECN gives the chance to respond to 1569 congestion before packets are dropped in the network, improving the 1570 user experience by allowing the RTP application to control how the 1571 quality is reduced. An application which ignores ECN congestion 1572 experienced feedback is not immune to congestion: the network will 1573 eventually begin to discard packets if traffic doesn't respond. It 1574 is in the best interest of an application to respond to ECN 1575 congestion feedback promptly, to avoid packet loss. 1577 7.4. Detecting Failures 1579 Senders and receivers can deliberately ignore ECN-CE and thus get a 1580 benefit over behaving flows (cheating). Nonce [RFC3540] is an 1581 addition to TCP that solves this issue as long as the sender acts on 1582 behalf of the network. The assumption about the senders acting on 1583 the behalf of the network may be reduced due to the nature of peer- 1584 to-peer use of RTP. Still a significant portion of RTP senders are 1585 infrastructure devices (for example, streaming media servers) that do 1586 have an interest in protecting both service quality and the network. 1587 Even though there may be cases where nonce can be applicable also for 1588 RTP, it is not included in this specification. This as a receiver 1589 interested in cheating would simple claim to not support Nonce. It 1590 is however worth mention that, as real-time media is commonly 1591 sensitive to increased delay and packet loss, it will be in both 1592 media sender and receivers interest to minimise the number and 1593 duration of any congestion events as they will affect media quality. 1595 RTP sessions can also suffer from path changes resulting in a non-ECN 1596 compliant node becoming part of the path. That node may perform 1597 either of two actions that has effect on the ECN and application 1598 functionality. The gravest is if the node drops packets with any ECN 1599 field values other than 00b. This can be detected by the receiver 1600 when it receives a RTCP SR packet indicating that a sender has sent a 1601 number of packets has not been received. The sender may also detect 1602 it based on the receivers RTCP RR packet where the extended sequence 1603 number is not advanced due to the failure to receive packets. If the 1604 packet loss is less than 100% then packet loss reporting in either 1605 the ECN feedback information or RTCP RR will indicate the situation. 1606 The other action is to re-mark a packet from ECT or CE to not-ECT. 1607 That has less dire results, however, it should be detected so that 1608 ECN usage can be suspended to prevent misusing the network. 1610 The ECN feedback packet allows the sender to compare the number of 1611 ECT marked packets of different type with the number it actually 1612 sent. The number of ECT packets received plus the number of CE 1613 marked and lost packets should correspond to the number of sent ECT 1614 marked packets unless there is duplication in the network. If this 1615 number doesn't agree there are two likely reasons, a translator 1616 changing the stream or not carrying the ECN markings forward, or that 1617 some node re-marks the packets. In both cases the usage of ECN is 1618 broken on the path. By tracking all the different possible ECN field 1619 values a sender can quickly detect if some non-compliant behavior is 1620 happing on the path. 1622 Thus packet losses and non-matching ECN field value statistics are 1623 possible indication of issues with using ECN over the path. The next 1624 section defines both sender and receiver reactions to these cases. 1626 7.4.1. Fallback mechanisms 1628 Upon the detection of a potential failure both the sender and the 1629 receiver can react to mitigate the situation. 1631 A receiver that detects a packet loss burst MAY schedule an early 1632 feedback packet to report this to the sender that includes at least 1633 the RTCP RR and the ECN feedback message. Thus speeding up the 1634 detection at the sender of the losses and thus triggering sender side 1635 mitigation. 1637 A sender that detects high packet loss rates for ECT-marked packets 1638 SHOULD immediately switch to sending packets as not-ECT to determine 1639 if the losses potentially are due to the ECT markings. If the losses 1640 disappear when the ECT-marking is discontinued, the RTP sender should 1641 go back to initiation procedures to attempt to verify the apparent 1642 loss of ECN capability of the used path. If a re-initiation fails 1643 then the two possible actions exist: 1645 1. Periodically retry the ECN initiation to detect if a path change 1646 occurs to a path that is ECN capable. 1648 2. Renegotiating the session to disable ECN support. This is a 1649 choice that is suitable if the impact of ECT probing on the media 1650 quality are noticeable. If multiple initiations has been 1651 successful but the following full usage of ECN has resulted in 1652 the fallback procedures then disabling of the ECN support is 1653 RECOMMENDED. 1655 We foresee the possibility of flapping ECN capability due to several 1656 reasons: video switching MCU or similar middleboxes that selects to 1657 deliver media from the sender only intermittently; load balancing 1658 devices may in worst case result in that some packets take a 1659 different network path then the others; mobility solutions that 1660 switch underlying network path in a transparent way for the sender or 1661 receiver; and membership changes in a multicast group. It is however 1662 appropriate to mention that there are also issues such as re-routing 1663 of traffic due to a flappy route table or excessive reordering and 1664 other issues that are not directly ECN related but nevertheless may 1665 cause problems for ECN. 1667 7.4.2. Interpretation of ECN Summary information 1669 This section contains discussion on how you can use the ECN summary 1670 report information in detecting various types of ECN path issues. 1671 Lets start to review the information the reports provide on a per 1672 source (SSRC) basis: 1674 CE Counter: The number of RTP packets received so far in the session 1675 with an ECN field set to CE (11b). 1677 ECT (0/1) Counters: The number of RTP packets received so far in the 1678 session with an ECN field set to ECT (0) and ECT (1) respectively 1679 (10b / 01b). 1681 not-ECT Counter: The number of RTP packets received so far in the 1682 session with an ECN field set to not-ECT (00b) 1684 Lost Packets counter: The number of RTP packets that are expected 1685 minus the number received. 1687 Extended Highest Sequence number: The highest sequence number seen 1688 when sending this report, but with additional bits, to handle 1689 disambiguation when wrapping the RTP sequence number field. 1691 The counters will be initiated to zero to provide value for the RTP 1692 stream sender from the very first report. After the first report the 1693 changes between the latest received and the previous one is 1694 determined by simply taking the values of the latest minus the 1695 previous one, taking field wrapping into account. This definition is 1696 also robust to packet losses, since if one report is missing, the 1697 reporting interval becomes longer, but is otherwise equally valid. 1699 In a perfect world the number of not-ECT packets received should be 1700 equal to the number sent minus the lost packets counter, and the sum 1701 of the ECT(0), ECT(1), and CE counters should be equal to the number 1702 of ECT marked packet sent. Two issues may cause a mismatch in these 1703 statistics: severe network congestion or unresponsive congestion 1704 control might cause some ECT-marked packets to be lost, and packet 1705 duplication might result in some packets being received, and counted 1706 in the statistics, multiple times (potentially with a different ECN- 1707 mark on each copy of the duplicate). 1709 The level of packet duplication included in the report can be 1710 estimated from the sum over all of fields counting received packets 1711 compared to the number of packets sent. A high level of packet 1712 duplication increases the uncertainty in the statistics, making it 1713 more difficult to draw firm conclusions about the behaviour of the 1714 network. This issue is also present with standard RTCP reception 1715 reports. 1717 Detecting clearing of ECN field: If the ratio between ECT and not-ECT 1718 transmitted in the reports has become all not-ECT or substantially 1719 changed towards not-ECT then this is clearly indication that the path 1720 results in clearing of the ECT field. 1722 Dropping of ECT packets: To determine if the packet drop ratio is 1723 different between not-ECT and ECT marked transmission requires a mix 1724 of transmitted traffic. The sender should compare if the delivery 1725 percentage (delivered / transmitted) between ECT and not-ECT is 1726 significantly different. Care must be taken if the number of packets 1727 are low in either of the categories. One must also take into account 1728 the level of CE marking. A CE marked packet would have been dropped 1729 unless it was ECT marked. Thus, the packet loss level for not-ECT 1730 should be aprroximately equal to the loss rate for ECT when counting 1731 the CE marked packets as lost ones. A sender performing this 1732 calculation needs to ensure that the difference is statistcally 1733 significant. 1735 If erronous behavior is detected, it should be logged to enable 1736 follow up and statistics gathering. 1738 8. Processing RTCP ECN Feedback in RTP Translators and Mixers 1740 RTP translators and mixers that support ECN feedback are required to 1741 process, and potentially modify or generate, RTCP packets for the 1742 translated and/or mixed streams. This includes both downstream RTCP 1743 reports generated by the media sender, and also reports generated by 1744 the receivers, flowing upstream back towards the sender. 1746 8.1. Fragmentation and Reassembly in Translators 1748 An RTP translator may fragment or reassemble RTP data packets without 1749 changing the media encoding, and without reference to the congestion 1750 state of the networks it bridges. An example of this might be to 1751 combine packets of a voice-over-IP stream coded with one 20ms frame 1752 per RTP packet into new RTP packets with two 20ms frames per packet, 1753 thereby reducing the header overheads and so stream bandwidth, at the 1754 expense of an increase in latency. If multiple data packets are re- 1755 encoded into one, or vice versa, the RTP translator MUST assign new 1756 sequence numbers to the outgoing packets. Losses in the incoming RTP 1757 packet stream may also induce corresponding gaps in the outgoing RTP 1758 sequence numbers. An RTP translator MUST rewrite RTCP packets to 1759 make the corresponding changes to their sequence numbers, and to 1760 reflect the impact of the fragmentation or reassembly. This section 1761 describes how that rewriting is to be done for RTCP ECN feedback 1762 packets. Section 7.2 of [RFC3550] describes general procedures for 1763 other RTCP packet types. 1765 RTCP ECN feedback packets (Section 5.1) contain six fields that are 1766 rewritten in an RTP translator that fragments or reassembles packets: 1767 the extended highest sequence number, the lost packets counter, the 1768 CE counter, and not-ECT counter, the ECT(0) counter, and the ECT(1) 1769 counter. The RTCP XR report block for ECN summary information 1770 (Section 5.2) includes a subset of these fields excluding the 1771 extended highest sequence number and lost packets counter. The 1772 procedures for rewriting these fields are the same for both types of 1773 RTCP ECN feedback packet. 1775 When receiving an RTCP ECN feedback packet for the translated stream, 1776 an RTP translator first determines the range of packets to which the 1777 report corresponds. The extended highest sequence number in the RTCP 1778 ECN feedback packet (or in the RTCP SR/RR packet contained within the 1779 compound packet, in the case of RTCP XR ECN summary reports) 1780 specifies the end sequence number of the range. For the first RTCP 1781 ECN feedback packet received, the initial extended sequence number of 1782 the range may be determined by subtracting the sum of the lost 1783 packets counter, the CE counter, the not-ECT counter, the ECT(0) 1784 counter and the ECT(1) counter from the extended highest sequence 1785 number (this will be inaccurate if there is packet duplication). For 1786 subsequent RTCP ECN feedback packets, the starting sequence number 1787 may be determined as being one after the extended highest sequence 1788 number of the previous RTCP ECN feedback packet received from the 1789 same SSRC. These values are in the sequence number space of the 1790 translated packets. 1792 Based on its knowledge of the translation process, the translator 1793 determines the sequence number range for the corresponding original, 1794 pre-translation, packets. The extended highest sequence number in 1795 the RTCP ECN feedback packet is rewritten to match the final sequence 1796 number in the pre-translation sequence number range. 1798 The translator then determines the ratio, R, of the number of packets 1799 in the translated sequence number space (numTrans) to the number of 1800 packets in the pre-translation sequence number space (numOrig) such 1801 that R = numTrans / numOrig. The counter values in the RTCP ECN 1802 feedback report are then scaled by dividing each of them by R. For 1803 example, if the translation process combines two RTP packets into 1804 one, then numOrig will be twice numTrans, giving R=0.5, and the 1805 counters in the translated RTCP ECN feedback packet will be twice 1806 those in the original. 1808 The ratio, R, may have a value that leads to non-integer multiples of 1809 the counters when translating the RTCP packet. For example, a VoIP 1810 translator that combines two adjacent RTP packets into one if they 1811 contain active speech data, but passes comfort noise packets 1812 unchanged, would have an R values of between 0.5 and 1.0 depending on 1813 the amount of active speech. Since the counter values in the 1814 translated RTCP report are integer values, rounding will be necessary 1815 in this case. 1817 When rounding counter values in the translated RTCP packet, the 1818 translator should try to ensure that they sum to the number of RTP 1819 packets in the pre-translation sequence number space (numOrig). The 1820 translator should also try to ensure that no non-zero counter is 1821 rounded to a zero value, since that will lose information that a 1822 particular type of event has occurred. It is recognised that it may 1823 be impossible to satisfy both of these constraints; in such cases, it 1824 is better to ensure that no non-zero counter is mapped to a zero 1825 value, since this preserves congestion adaptation and helps the RTCP- 1826 based ECN initiation process. 1828 It should be noted that scaling the RTCP counter values in this way 1829 is meaningful only on the assumption that the level of congestion in 1830 the network is related to the number of packets being sent. This is 1831 likely to be a reasonable assumption in the type of environment where 1832 RTP translators that fragment or reassemble packets are deployed, as 1833 their entire purpose is to change the number of packets being sent to 1834 adapt to known limitations of the network, but is not necessarily 1835 valid in general. 1837 The rewritten RTCP ECN feedback report is sent from the other side of 1838 the translator to that which it arrived (as part of a compound RTCP 1839 packet containing other translated RTCP packets, where appropriate). 1841 8.2. Generating RTCP ECN Feedback in Media Transcoders 1843 An RTP translator that acts as a media transcoder cannot directly 1844 forward RTCP packets corresponding to the transcoded stream, since 1845 those packets will relate to the non-transcoded stream, and will not 1846 be useful in relation to the transcoded RTP flow. Such a transcoder 1847 will need to interpose itself into the RTCP flow, acting as a proxy 1848 for the receiver to generate RTCP feedback in the direction of the 1849 sender relating to the pre-transcoded stream, and acting in place of 1850 the sender to generate RTCP relating to the transcoded stream, to be 1851 sent towards the receiver. This section describes how this proxying 1852 is to be done for RTCP ECN feedback packets. Section 7.2 of 1853 [RFC3550] describes general procedures for other RTCP packet types. 1855 An RTP translator acting as a media transcoder in this manner does 1856 not have its own SSRC, and hence is not visible to other entities at 1857 the RTP layer. RTCP ECN feedback packets and RTCP XR report blocks 1858 for ECN summary information that are received from downstream relate 1859 to the translated stream, and so must be processed by the translator 1860 as if it were the original media source. These reports drive the 1861 congestion control loop and media adaptation between the translator 1862 and the downstream receiver. If there are multiple downstream 1863 receivers, a logically separate transcoder instance must be used for 1864 each receiver, and must process RTCP ECN feedback and summary reports 1865 independently to the other transcoder instances. An RTP translator 1866 acting as a media transcoder in this manner MUST NOT forward RTCP ECN 1867 feedback packets or RTCP XR ECN summary reports from downstream 1868 receivers in the upstream direction. 1870 An RTP translator acting as a media transcoder will generate RTCP 1871 reports upstream towards the original media sender, based on the 1872 reception quality of the original media stream at the translator. 1873 The translator will run a separate congestion control loop and media 1874 adaptation between itself and the media sender for each of its 1875 downstream receivers, and must generate RTCP ECN feedback packets and 1876 RTCP XR ECN summary reports for that congestion control loop using 1877 the SSRC of that downstream receiver. 1879 8.3. Generating RTCP ECN Feedback in Mixers 1881 An RTP mixer terminates one-or-more RTP flows, combines them into a 1882 single outgoing media stream, and transmits that new stream as a 1883 separate RTP flow. A mixer has its own SSRC, and is visible to other 1884 participants in the session at the RTP layer. 1886 An ECN-aware RTP mixer must generate RTCP ECN feedback packets and 1887 RTCP XR report blocks for ECN summary information relating to the RTP 1888 flows it terminates, in exactly the same way it would if it were an 1889 RTP receiver. These reports form part of the congestion control loop 1890 between the mixer and the media senders generating the streams it is 1891 mixing. A separate control loop runs between each sender and the 1892 mixer. 1894 An ECN-aware RTP mixer will negotiate and initiate the use of ECN on 1895 the mixed flows it generates, and will accept and process RTCP ECN 1896 feedback reports and RTCP XR report blocks for ECN relating to those 1897 mixed flows as if it were a standard media sender. A congestion 1898 control loop runs between the mixer and its receivers, driven in part 1899 by the ECN reports received. 1901 An RTP mixer MUST NOT forward RTCP ECN feedback packets or RTCP XR 1902 ECN summary reports reports from downstream receivers in the upstream 1903 direction. 1905 9. Implementation considerations 1907 To allow the use of ECN with RTP over UDP, the RTP implementation 1908 must be able to set the ECT bits in outgoing UDP datagrams, and must 1909 be able to read the value of the ECT bits on received UDP datagrams. 1910 The standard Berkeley sockets API pre-dates the specification of ECN, 1911 and does not provide the functionality which is required for this 1912 mechanism to be used with UDP flows, making this specification 1913 difficult to implement portably. 1915 10. IANA Considerations 1917 Note to RFC Editor: please replace "RFC XXXX" below with the RFC 1918 number of this memo, and remove this note. 1920 10.1. SDP Attribute Registration 1922 Following the guidelines in [RFC4566], the IANA is requested to 1923 register one new SDP attribute: 1925 o Contact name, email address and telephone number: Authors of 1926 RFCXXXX 1928 o Attribute-name: ecn-capable-rtp 1930 o Type of attribute: media-level 1932 o Subject to charset: no 1934 This attribute defines the ability to negotiate the use of ECT (ECN 1935 capable transport). This attribute should be put in the SDP offer if 1936 the offering party wishes to receive an ECT flow. The answering 1937 party should include the attribute in the answer if it wish to 1938 receive an ECT flow. If the answerer does not include the attribute 1939 then ECT MUST be disabled in both directions. 1941 10.2. RTP/AVPF Transport Layer Feedback Message 1943 The IANA is requested to register one new RTP/AVPF Transport Layer 1944 Feedback Message in the table of FMT values for RTPFB Payload Types 1945 [RFC4585] as defined in Section 5.1: 1947 Name: RTCP-ECN-FB 1948 Long name: RTCP ECN Feedback 1949 Value: TBA1 1950 Reference: RFC XXXX 1952 10.3. RTCP Feedback SDP Parameter 1954 The IANA is requested to register one new SDP "rtcp-fb" attribute 1955 "nack" parameter "ecn" in the SDP ("ack" and "nack" Attribute Values) 1956 registry. 1958 Value name: ecn 1959 Long name: Explicit Congestion Notification 1960 Usable with: nack 1961 Reference: RFC XXXX 1963 10.4. RTCP XR Report blocks 1965 The IANA is requested to register one new RTCP XR Block Type as 1966 defined in Section 5.2: 1968 Block Type: TBA2 1969 Name: ECN Summary Report 1970 Reference: RFC XXXX 1972 10.5. RTCP XR SDP Parameter 1974 The IANA is requested to register one new RTCP XR SDP Parameter "ecn- 1975 sum" in the "RTCP XR SDP Parameters" registry. 1977 Parameter name XR block (block type and name) 1978 -------------- ------------------------------------ 1979 ecn-sum TBA2 ECN Summary Report Block 1981 10.6. STUN attribute 1983 A new STUN [RFC5389] attribute in the Comprehension-optional range 1984 under IETF Review (0x0000 - 0x3FFF) is request to be assigned to the 1985 STUN attribute defined in Section 7.2.2. The STUN attribute registry 1986 can currently be found at: http://www.iana.org/assignments/ 1987 stun-parameters/stun-parameters.xhtml. 1989 10.7. ICE Option 1991 A new ICE option "rtp+ecn" is registered in the registry that "IANA 1992 Registry for Interactive Connectivity Establishment (ICE) Options" 1993 [I-D.ietf-mmusic-ice-options-registry] creates. 1995 11. Security Considerations 1997 The usage of ECN with RTP over UDP as specified in this document has 1998 the following known security issues that needs to be considered. 2000 External threats to the RTP and RTCP traffic: 2002 Denial of Service affecting RTCP: For an attacker that can modify 2003 the traffic between the media sender and a receiver can achieve 2004 either of two things. 1. Report a lot of packets as being 2005 Congestion Experience marked, thus forcing the sender into a 2006 congestion response. 2. Ensure that the sender disable the usage 2007 of ECN by reporting failures to receive ECN by changing the 2008 counter fields. The Issue, can also be accomplished by injecting 2009 false RTCP packets to the media sender. Reporting a lot of CE 2010 marked traffic is likely the more efficient denial of service tool 2011 as that may likely force the application to use lowest possible 2012 bit-rates. The prevention against an external threat is to 2013 integrity protect the RTCP feedback information and authenticate 2014 the sender of it. 2016 Information leakage: The ECN feedback mechanism exposes the 2017 receivers perceived packet loss, what packets it considers to be 2018 ECN-CE marked and its calculation of the ECN-none. This is mostly 2019 not considered sensitive information. If considered sensitive the 2020 RTCP feedback shall be encrypted. 2022 Changing the ECN bits An on-path attacker that see the RTP packet 2023 flow from sender to receiver and who has the capability to change 2024 the packets can rewrite ECT into ECN-CE thus forcing the sender or 2025 receiver to take congestion control response. This denial of 2026 service against the media quality in the RTP session is impossible 2027 for en end-point to protect itself against. Only network 2028 infrastructure nodes can detect this illicit re-marking. It will 2029 be mitigated by turning off ECN, however, if the attacker can 2030 modify its response to drop packets the same vulnerability exist. 2032 Denial of Service affecting the session set-up signalling: If an 2033 attacker can modify the session signalling it can prevent the 2034 usage of ECN by removing the signalling attributes used to 2035 indicate that the initiator is capable and willing to use ECN with 2036 RTP/UDP. This attack can be prevented by authentication and 2037 integrity protection of the signalling. We do note that any 2038 attacker that can modify the signalling has more interesting 2039 attacks they can perform than prevent the usage of ECN, like 2040 inserting itself as a middleman in the media flows enabling wire- 2041 tapping also for an off-path attacker. 2043 The following are threats that exist from misbehaving senders or 2044 receivers: 2046 Receivers cheating A receiver may attempt to cheat and fail to 2047 report reception of ECN-CE marked packets. The benefit for a 2048 receiver cheating in its reporting would be to get an unfair bit- 2049 rate share across the resource bottleneck. It is far from certain 2050 that a receiver would be able to get a significant larger share of 2051 the resources. That assumes a high enough level of aggregation 2052 that there are flows to acquire shares from. The risk of cheating 2053 is that failure to react to congestion results in packet loss and 2054 increased path delay. 2056 Receivers misbehaving: A receiver may prevent the usage of ECN in an 2057 RTP session by reporting itself as non ECN capable. Thus forcing 2058 the sender to turn off usage of ECN. In a point-to-point scenario 2059 there is little incentive to do this as it will only affect the 2060 receiver. Thus failing to utilise an optimisation. For multi- 2061 party session there exist some motivation why a receiver would 2062 misbehave as it can prevent also the other receivers from using 2063 ECN. As an insider into the session it is difficult to determine 2064 if a receiver is misbehaving or simply incapable, making it 2065 basically impossible in the incremental deployment phase of ECN 2066 for RTP usage to determine this. If additional information about 2067 the receivers and the network is known it might be possible to 2068 deduce that a receiver is misbehaving. If it can be determined 2069 that a receiver is misbehaving, the only response is to exclude it 2070 from the RTP session and ensure that is doesn't any longer have 2071 any valid security context to affect the session. 2073 Misbehaving Senders: The enabling of ECN gives the media packets a 2074 higher degree of probability to reach the receiver compared to 2075 not-ECT marked ones on a ECN capable path. However, this is no 2076 magic bullet and failure to react to congestion will most likely 2077 only slightly delay a buffer under-run, in which its session also 2078 will experience packet loss and increased delay. There are some 2079 chance that the media senders traffic will push other traffic out 2080 of the way without being effected to negatively. However, we do 2081 note that a media sender still needs to implement congestion 2082 control functions to prevent the media from being badly affected 2083 by congestion events. Thus the misbehaving sender is getting a 2084 unfair share. This can only be detected and potentially prevented 2085 by network monitoring and administrative entities. See Section 7 2086 of [RFC3168] for more discussion of this issue. 2088 We note that the end-point security functions needs to prevent an 2089 external attacker from affecting the solution easily are source 2090 authentication and integrity protection. To prevent what information 2091 leakage there can be from the feedback encryption of the RTCP is also 2092 needed. For RTP there exist multiple solutions possible depending on 2093 the application context. Secure RTP (SRTP) [RFC3711] does satisfy 2094 the requirement to protect this mechanism despite only providing 2095 authentication if a entity is within the security context or not. 2096 IPsec [RFC4301] and DTLS [RFC4347] can also provide the necessary 2097 security functions. 2099 The signalling protocols used to initiate an RTP session also needs 2100 to be source authenticated and integrity protected to prevent an 2101 external attacker from modifying any signalling. Here an appropriate 2102 mechanism to protect the used signalling needs to be used. For SIP/ 2103 SDP ideally S/MIME [RFC5751] would be used. However, with the 2104 limited deployment a minimal mitigation strategy is to require use of 2105 SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least accomplish hop- 2106 by-hop protection. 2108 We do note that certain mitigation methods will require network 2109 functions. 2111 12. Examples of SDP Signalling 2113 This section contain a few different examples of the signalling 2114 mechanism defined in this specification in an SDP context. If there 2115 is discrepancies between these examples and the specification text, 2116 the specification text is what is correct. 2118 12.1. Basic SDP Offer/Answer 2120 This example is a basic offer/answer SDP exchange, assumed done by 2121 SIP (not shown). The intention is to establish a basic audio session 2122 point to point between two users. 2124 The Offer: 2126 v=0 2127 o=jdoe 3502844782 3502844782 IN IP4 10.0.1.4 2128 s=VoIP call 2129 i=SDP offer for VoIP call with ICE and ECN for RTP 2130 b=AS:128 2131 b=RR:2000 2132 b=RS:2500 2133 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh 2134 a=ice-ufrag:9uB6 2135 a=ice-options:rtp+ecn 2136 t=0 0 2137 m=audio 45664 RTP/AVPF 97 98 99 2138 c=IN IP4 192.0.2.3 2139 a=rtpmap:97 G719/48000/1 2140 a=fmtp:97 maxred=160 2141 a=rtpmap:98 AMR-WB/16000/1 2142 a=fmtp:98 octet-align=1; mode-change-capability=2 2143 a=rtpmap:99 PCMA/8000/1 2144 a=maxptime:160 2145 a=ptime:20 2146 a=ecn-capable-rtp: ice rtp ect=0 mode=setread 2147 a=rtcp-fb:* nack ecn 2148 a=rtcp-fb:* trr-int 1000 2149 a=rtcp-xr:ecn-sum 2150 a=candidate:1 1 UDP 2130706431 10.0.1.4 8998 typ host 2151 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 2152 10.0.1.4 rport 8998 2154 This SDP offer offers a single media stream with 3 media payload 2155 types. It proposes to use ECN with RTP, with the ICE based 2156 initilziation as being prefered over the RTP/RTCP one. Leap of faith 2157 is not suggested to be used. The offerer is capable of both setting 2158 and reading the ECN bits. In addition the RTCP ECN feedback packet 2159 is configured and the RTCP XR ECN summary report. ICE is also 2160 proposed with two candidates. 2162 The Answer: 2164 v=0 2165 o=jdoe 3502844783 3502844783 IN IP4 198.51.100.235 2166 s=VoIP call 2167 i=SDP offer for VoIP call with ICE and ECN for RTP 2168 b=AS:128 2169 b=RR:2000 2170 b=RS:2500 2171 a=ice-pwd:asd88fgpdd777uzjYhagZg 2172 a=ice-ufrag:8hhY 2173 a=ice-options:rtp+ecn 2174 t=0 0 2175 m=audio 53879 RTP/AVPF 97 99 2176 c=IN IP4 198.51.100.235 2177 a=rtpmap:97 G719/48000/1 2178 a=fmtp:97 maxred=160 2179 a=rtpmap:99 PCMA/8000/1 2180 a=maxptime:160 2181 a=ptime:20 2182 a=ecn-capable-rtp: ice ect=0 mode=readonly 2183 a=rtcp-fb:* nack ecn 2184 a=rtcp-fb:* trr-int 1000 2185 a=rtcp-xr:ecn-sum 2186 a=candidate:1 1 UDP 2130706431 198.51.100.235 53879 typ host 2188 The answer confirms that only one media stream will be used. One RTP 2189 Payload type was removed. ECN capability was confirmed, and the 2190 initilization method will be ICE. However, the answerer is only 2191 capable of reading the ECN bits, which means that ECN can only be 2192 used for RTP flowing from the offerer to the answerer. ECT always 2193 set to 0 will be used in both directions. Both the RTCP ECN feedback 2194 packet and the RTCP XR ECN summary report will be used. 2196 12.2. Declarative Multicast SDP 2198 The below session describes an any source multicast using session 2199 with a single media stream. 2201 v=0 2202 o=jdoe 3502844782 3502844782 IN IP4 198.51.100.235 2203 s=Multicast SDP session using ECN for RTP 2204 i=Multicasted audio chat using ECN for RTP 2205 b=AS:128 2206 t=3502892703 3502910700 2207 m=audio 56144 RTP/AVPF 97 2208 c=IN IP4 233.252.0.212/127 2209 a=rtpmap:97 g719/48000/1 2210 a=fmtp:97 maxred=160 2211 a=maxptime:160 2212 a=ptime:20 2213 a=ecn-capable-rtp: rtp mode=readonly; ect=0 2214 a=rtcp-fb:* nack ecn 2215 a=rtcp-fb:* trr-int 1500 2216 a=rtcp-xr:ecn-sum 2218 In the above example, as this is declarative we need to require 2219 certain functionality. As it is ASM the initliziation method that 2220 can work here is the RTP/RTCP based one. So that is indicated. The 2221 ECN setting and reading capability to take part of this session is at 2222 least read. If one is capable of setting that is good, but not 2223 required as one can skip using ECN for anything one send oneself. 2224 The ECT value is recommended to be set to 0 always. The ECN usage in 2225 this session requires both ECN feedback and the XR ECN summary 2226 report, so their usage are also indicated. 2228 13. Open Issues 2230 As this draft is under development some known open issues exist and 2231 are collected here. Please consider them and provide input. 2233 1. The negotiation and directionality attribute is going to need 2234 some consideration for multi-party sessions when readonly 2235 capability might be sufficient to enable ECN for all incoming 2236 streams. However, it would beneficial to know if no potential 2237 sender support setting ECN. 2239 2. Consider initiation optimizations that allows for multi SSRC 2240 sender nodes to still have rapid usage of ECN. 2242 3. Should we report congestion in bytes or packets? RTCP usually 2243 does this in terms of packets, but there may be an argument that 2244 we want to report bytes for ECN. 2245 draft-ietf-tsvwg-byte-pkt-congest is extremely unclear on what is 2246 the right approach. 2248 4. We have a saturation problem with the packet loss counters. They 2249 do need to continue working even if saturation happens due to 2250 long sessions where more lost packets than the counters can 2251 handle. 2253 14. Acknowledgments 2255 The authors wish to thank the following persons for their reviews and 2256 comments: Thomas Belling, Bob Briscoe, Roni Even, Thomas Frankkila, 2257 Christian Groves, Cullen Jennings Tom Van Caenegem, Simo 2258 Veikkolainen, Lei Zhu, Christer Holmgren. 2260 15. References 2262 15.1. Normative References 2264 [I-D.ietf-mmusic-ice-options-registry] 2265 Westerlund, M. and C. Perkins, "IANA Registry for 2266 Interactive Connectivity Establishment (ICE) Options", 2267 draft-ietf-mmusic-ice-options-registry-00 (work in 2268 progress), January 2011. 2270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2271 Requirement Levels", BCP 14, RFC 2119, March 1997. 2273 [RFC2762] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group 2274 Membership in RTP", RFC 2762, February 2000. 2276 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2277 of Explicit Congestion Notification (ECN) to IP", 2278 RFC 3168, September 2001. 2280 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2281 Jacobson, "RTP: A Transport Protocol for Real-Time 2282 Applications", STD 64, RFC 3550, July 2003. 2284 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 2285 Protocol Extended Reports (RTCP XR)", RFC 3611, 2286 November 2003. 2288 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2289 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2291 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2292 (ICE): A Protocol for Network Address Translator (NAT) 2293 Traversal for Offer/Answer Protocols", RFC 5245, 2294 April 2010. 2296 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 2297 Friendly Rate Control (TFRC): Protocol Specification", 2298 RFC 5348, September 2008. 2300 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2301 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 2302 October 2008. 2304 15.2. Informative References 2306 [I-D.ietf-avt-rtp-no-op] 2307 Andreasen, F., "A No-Op Payload Format for RTP", 2308 draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. 2310 [I-D.zimmermann-avt-zrtp] 2311 Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 2312 Path Key Agreement for Unicast Secure RTP", 2313 draft-zimmermann-avt-zrtp-22 (work in progress), 2314 June 2010. 2316 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2317 Announcement Protocol", RFC 2974, October 2000. 2319 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2320 A., Peterson, J., Sparks, R., Handley, M., and E. 2321 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2322 June 2002. 2324 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2325 with Session Description Protocol (SDP)", RFC 3264, 2326 June 2002. 2328 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 2329 Congestion Notification (ECN) Signaling with Nonces", 2330 RFC 3540, June 2003. 2332 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2333 Video Conferences with Minimal Control", STD 65, RFC 3551, 2334 July 2003. 2336 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 2337 Multicast (SSM)", RFC 3569, July 2003. 2339 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2340 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2341 RFC 3711, March 2004. 2343 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2344 Internet Protocol", RFC 4301, December 2005. 2346 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2347 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 2349 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2350 Security", RFC 4347, April 2006. 2352 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2353 Description Protocol", RFC 4566, July 2006. 2355 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2356 "Extended RTP Profile for Real-time Transport Control 2357 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2358 July 2006. 2360 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 2361 IP", RFC 4607, August 2006. 2363 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 2364 RFC 4960, September 2007. 2366 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 2367 Real-time Transport Control Protocol (RTCP)-Based Feedback 2368 (RTP/SAVPF)", RFC 5124, February 2008. 2370 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 2371 Real-Time Transport Control Protocol (RTCP): Opportunities 2372 and Consequences", RFC 5506, April 2009. 2374 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 2375 Initiation Protocol (SIP)", RFC 5630, October 2009. 2377 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2378 Mail Extensions (S/MIME) Version 3.2 Message 2379 Specification", RFC 5751, January 2010. 2381 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 2382 Protocol (RTCP) Extensions for Single-Source Multicast 2383 Sessions with Unicast Feedback", RFC 5760, February 2010. 2385 Authors' Addresses 2387 Magnus Westerlund 2388 Ericsson 2389 Farogatan 6 2390 SE-164 80 Kista 2391 Sweden 2393 Phone: +46 10 714 82 87 2394 Email: magnus.westerlund@ericsson.com 2396 Ingemar Johansson 2397 Ericsson 2398 Laboratoriegrand 11 2399 SE-971 28 Lulea 2400 SWEDEN 2402 Phone: +46 73 0783289 2403 Email: ingemar.s.johansson@ericsson.com 2405 Colin Perkins 2406 University of Glasgow 2407 School of Computing Science 2408 Glasgow G12 8QQ 2409 United Kingdom 2411 Email: csp@csperkins.org 2413 Piers O'Hanlon 2414 University College London 2415 Computer Science Department 2416 Gower Street 2417 London WC1E 6BT 2418 United Kingdom 2420 Email: p.ohanlon@cs.ucl.ac.uk 2421 Ken Carlberg 2422 G11 2423 1600 Clarendon Blvd 2424 Arlington VA 2425 USA 2427 Email: carlberg@g11.org.uk