idnits 2.17.1 draft-ietf-avtcore-ecn-for-rtp-02.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 (May 31, 2011) is 4712 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 680, but not defined == Missing Reference: 'TBA2' is mentioned on line 840, but not defined ** 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 (~~), 4 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: December 2, 2011 C. Perkins 6 University of Glasgow 7 P. O'Hanlon 8 UCL 9 K. Carlberg 10 G11 11 May 31, 2011 13 Explicit Congestion Notification (ECN) for RTP over UDP 14 draft-ietf-avtcore-ecn-for-rtp-02 16 Abstract 18 This memo specifies how Explicit Congestion Notification (ECN) can be 19 used with Real-time Transport Protocol (RTP) running over UDP, using 20 RTP Control Protocol (RTCP) as a feedback mechanism. It defines a 21 new RTCP Extended Report (XR) block for periodic ECN feedback, a new 22 RTCP transport feedback message for timely reporting of congestion 23 events, and a Session Traversal Utilities for NAT (STUN) extension 24 used in the optional initilization method using Interactive 25 Connectivity Establishment (ICE). Signalling and procedures for 26 negotiation of capabilities and initilization methods are also 27 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 December 2, 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 . . . . . . . . . . . . . . . . . . . . . . . 7 67 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 8 68 3.3. Interoperability . . . . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . 15 72 5.2. RTCP XR Report block for ECN summary information . . . . . 18 73 6. SDP Signalling Extensions for ECN . . . . . . . . . . . . . . 20 74 6.1. Signalling ECN Capability using SDP . . . . . . . . . . . 20 75 6.2. RTCP ECN Feedback SDP Parameter . . . . . . . . . . . . . 25 76 6.3. XR Block ECN SDP Parameter . . . . . . . . . . . . . . . . 25 77 6.4. ICE Parameter to Signal ECN Capability . . . . . . . . . . 25 78 7. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 26 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 . . . . . . . . . 33 82 7.4. Detecting Failures . . . . . . . . . . . . . . . . . . . . 36 83 8. Processing ECN in RTP Translators and Mixers . . . . . . . . . 39 84 8.1. Transport Translators . . . . . . . . . . . . . . . . . . 40 85 8.2. Fragmentation and Reassembly in Translators . . . . . . . 40 86 8.3. Generating RTCP ECN Feedback in Media Transcoders . . . . 42 87 8.4. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 43 88 9. Implementation considerations . . . . . . . . . . . . . . . . 44 89 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 90 10.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 44 91 10.2. RTP/AVPF Transport Layer Feedback Message . . . . . . . . 44 92 10.3. RTCP Feedback SDP Parameter . . . . . . . . . . . . . . . 45 93 10.4. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 45 94 10.5. RTCP XR SDP Parameter . . . . . . . . . . . . . . . . . . 45 95 10.6. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 45 96 10.7. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 45 97 11. Security Considerations . . . . . . . . . . . . . . . . . . . 46 98 12. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 48 99 12.1. Basic SDP Offer/Answer . . . . . . . . . . . . . . . . . . 48 100 12.2. Declarative Multicast SDP . . . . . . . . . . . . . . . . 50 101 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 51 102 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 52 103 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 104 15.1. Normative References . . . . . . . . . . . . . . . . . . . 52 105 15.2. Informative References . . . . . . . . . . . . . . . . . . 53 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 108 1. Introduction 110 This memo outlines how Explicit Congestion Notification (ECN) 111 [RFC3168] can be used for Real-time Transport Protocol (RTP) 112 [RFC3550] flows running over UDP/IP which use RTP Control Protocol 113 (RTCP) as a feedback mechanism. The solution consists of feedback of 114 ECN congestion experienced markings to the sender using RTCP, 115 verification of ECN functionality end-to-end, and procedures for how 116 to initiate ECN usage. The initiation process will have some 117 dependencies on the signalling mechanism used to establish the RTP 118 session, a specification for signalling mechanisms using Session 119 Description Protocol (SDP) [RFC4566] is included. 121 ECN is getting attention as a method to minimise the impact of 122 congestion on real-time multimedia traffic. The use of ECN provides 123 a way for the network to send a congestion control signal to a media 124 transport without having to impair the media. Unlike packet loss, 125 ECN signals unambiguously indicate congestion to the transport as 126 quickly as feedback delays allow, and without confusing congestion 127 with losses that might have occurred for other reasons such as 128 transmission errors, packet-size errors, routing errors, badly 129 implemented middleboxes, policy violations and so forth. 131 The introduction of ECN into the Internet requires changes to both 132 the network and transport layers. At the network layer, IP 133 forwarding has to be updated to allow routers to mark packets, rather 134 than discarding them in times of congestion [RFC3168]. In addition, 135 transport protocols have to be modified to inform the sender that ECN 136 marked packets are being received, so it can respond to the 137 congestion. The Transmission Control Protocol (TCP) [RFC3168], 138 Stream Control Transmission Protocol (SCTP) [RFC4960] and Datagram 139 Congestion Control Protocl (DCCP) [RFC4340] have been updated to 140 support ECN, but to date there is no specification how UDP-based 141 transports, such as RTP [RFC3550], can use ECN. This is due to the 142 lack of feedback mechanisms directly in UDP. Instead the signaling 143 control protocol on top of UDP needs to provide that feedback. For 144 RTP that feedback is provided by RTCP. 146 The remainder of this memo is structured as follows. We start by 147 describing the conventions, definitions and acronyms used in this 148 memo in Section 2, and the design rationale and applicability in 149 Section 3. Section 4 gives an overview of how ECN is used with RTP 150 over UDP. RTCP extensions for ECN feedback are defined in Section 5, 151 and SDP signalling extensions in Section 6. The details of how ECN 152 is used with RTP over UDP are defined in Section 7. In Section 8 we 153 describe how ECN is handled in RTP translators and mixers. Section 9 154 discusses some implementation considerations, Section 10 lists IANA 155 considerations, and Section 11 discusses security considerations. 157 2. Conventions, Definitions and Acronyms 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in RFC 162 2119 [RFC2119]. 164 Abbreviations and Definitions: 166 Sender: A sender of RTP packets carrying an encoded media stream. 167 The sender has the possibility to effect how this transmission is 168 performed. It is one end-point of the ECN control loop. 170 Receiver: A receiver of RTP packets with the intention to consume 171 the media stream. It sends RTCP feedback on the received stream. 172 It is the other end-point of the ECN control loop. 174 ECN Capable Host: A sender or receiver of a media stream that is 175 capable of setting and/or processing ECN marks. 177 ECN Capable Transport (ECT): A transport flow where both sender and 178 receiver are ECN capable hosts. Packets sent by an ECN Capable 179 Transport will be marked as ECT(0) or ECT(1) on transmission. 181 ECN-CE: ECN Congestion Experienced mark 183 ECN Capable Packets: Packets with ECN mark set to either ECT(0), 184 ECT(1) or ECN-CE. 186 Not-ECT packets: Packets that are not sent by an ECN capable 187 transport, and are not ECN-CE marked. 189 ECN Oblivious Relay: A router or middlebox that treats ECN Capable 190 Packets no differently from Not-ECT packets. 192 ECN Capable Queue: A queue that supports ECN-CE marking of ECN- 193 Capable Packets to indicate congestion. 195 ECN Blocking Middlebox: A middlebox that discards ECN-Capable 196 Packets. 198 ECN Reverting Middlebox: A middlebox that changes ECN-Capable 199 Packets to Not-ECT packets by removing the ECN mark. 201 Note that RTP mixers or translators that operate in such a manner 202 that they terminate or split the ECN control loop will take on the 203 role of receivers or senders. This is further discussed in 204 Section 3.2. 206 3. Discussion, Requirements, and Design Rationale 208 ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960], 209 and DCCP [RFC4340] transports. These are all unicast protocols which 210 negotiate the use of ECN during the initial connection establishment 211 handshake (supporting incremental deployment, and checking if ECN 212 marked packets pass all middleboxes on the path). ECN-CE marks are 213 immediately echoed back to the sender by the receiving end-point 214 using an additional bit in feedback messages, and the sender then 215 interprets the mark as equivalent to a packet loss for congestion 216 control purposes. 218 If RTP is run over TCP, SCTP, or DCCP, it can use the native ECN 219 support provided by those protocols. This memo does not concern 220 itself further with these use cases. However, RTP is more commonly 221 run over UDP. This combination does not currently support ECN, and 222 we observe that it has significant differences from the other 223 transport protocols for which ECN has been specified. These include: 225 Signalling: RTP relies on separate signalling protocols to negotiate 226 parameters before a session can be created, and doesn't include an 227 in-band handshake or negotiation at session set-up time (i.e., 228 there is no equivalent to the TCP three-way handshake in RTP). 230 Feedback: RTP does not explicitly acknowledge receipt of datagrams. 231 Instead, the RTP Control Protocol (RTCP) provides reception 232 quality feedback, and other back channel communication, for RTP 233 sessions. The feedback interval is generally on the order of 234 seconds, rather than once per network RTT (although the RTP/AVPF 235 profile [RFC4585] allows more rapid feedback in most cases). RTCP 236 is also very much oriented around counting packets, which makes 237 byte counting congestion algorithms difficult to utilize. 239 Congestion Response: While it is possible to adapt the transmission 240 of many audio/visual streams in response to network congestion, 241 and such adaptation is required by [RFC3550], the dynamics of the 242 congestion response may be quite different to those of TCP or 243 other transport protocols. 245 Middleboxes: The RTP framework explicitly supports the concept of 246 mixers and translators, which are middleboxes that are involved in 247 media transport functions. 249 Multicast: RTP is explicitly a group communication protocol, and was 250 designed from the start to support IP multicast (primarily Any 251 Source Multicast (ASM) [RFC1112], although a recent extension 252 supports Source Specific Multicast (SSM) [RFC3569] with unicast 253 feedback [RFC5760]). 255 Application Awareness: When ECN support is provided within the 256 transport protocol, the ability of the application to react to 257 congestion is limited, since it has little visibility into the 258 transport layer. By adding support of ECN to RTP using RTCP 259 feedback, the application is made aware of congestion, allowing a 260 wider range of reactions in response to that loss. 262 Counting vs Detecting Congestion: TCP and the protocols derived from 263 it are mainly designed to respond the same whether they experience 264 a burst of congestion indications within one RTT or just one. 265 Whereas real-time applications may be concerned with the amount of 266 congestion experienced, whether it is distributed smoothly or in 267 bursts. When feedback of ECN was added to TCP [RFC3168], the 268 receiver was designed to flip the echo congestion experienced 269 (ECE) flag to 1 for a whole RTT then flop it back to zero. 270 Whereas ECN feedback in RTCP will need to report a count of how 271 much congestion has been experienced within an RTCP reporting 272 period, irrespective of round trip times. 274 These differences will significantly alter the shape of ECN support 275 in RTP-over-UDP compared to ECN support in TCP, SCTP, and DCCP, but 276 do not invalidate the need for ECN support. 278 ECN support is more important for RTP sessions than, for instance, is 279 the case for TCP. This is because the impact of packet loss in real- 280 time audio-visual media flows is highly visible to users. Effective 281 ECN support for RTP flows running over UDP will allow real-time 282 audio-visual applications to respond to the onset of congestion 283 before routers are forced to drop packets, allowing those 284 applications to control how they reduce their transmission rate, and 285 hence media quality, rather than responding to, and trying to conceal 286 the effects of unpredictable packet loss. Furthermore, widespread 287 deployment for ECN and active queue management in routers, should it 288 occur, can potentially reduce unnecessary queueing delays in routers, 289 lowering the round-trip time and benefiting interactive applications 290 of RTP, such as voice telephony. 292 3.1. Requirements 294 Considering ECN, transport protocols supporting ECN, and RTP based 295 applications one can create a set of requirements that must be 296 satisfied to at least some degree if ECN is to used by RTP over UDP. 298 o REQ 1: A mechanism MUST exist to negotiate and initiate the use of 299 ECN for RTP/UDP/IP sessions so that an RTP sender will not send 300 packets with ECT in the IP header unless it knows that all 301 potential receivers will understand any CE indications they might 302 receive. 304 o REQ 2: A mechanism MUST exist to feed back the reception of any 305 packets that are ECN-CE marked to the packet sender. 307 o REQ 3: The provided mechanism SHOULD minimise the possibility of 308 cheating (either by the sender or receiver). 310 o REQ 4: Some detection and fallback mechanism SHOULD exist to avoid 311 loss of communication due to the attempted usage of ECN in case an 312 intermediate node clears ECT or drops packets that are ECT marked. 314 o REQ 5: Negotiation of ECN SHOULD NOT significantly increase the 315 time taken to negotiate and set-up the RTP session (an extra RTT 316 before the media can flow is unlikely to be acceptable for some 317 use cases). 319 o REQ 6: Negotiation of ECN SHOULD NOT cause media clipping at the 320 start of a session. 322 The following sections describes how these requirements can be met 323 for RTP over UDP. 325 3.2. Applicability 327 The use of ECN with RTP over UDP is dependent on negotiation of ECN 328 capability between the sender and receiver(s), and validation of ECN 329 support in all elements of the network path(s) traversed. RTP is 330 used in a heterogeneous range of network environments and topologies, 331 with various different signalling protocols. The mechanisms defined 332 here make it possible to verify support for ECN in each of these 333 environments, and irrespective of the topology. 335 Due to the need for each RTP sender that intends 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 use of ECN is further dependent on a capability of the RTP media 341 flow to react to congestion signalled by ECN marked packets. 342 Depending on the application, media codec, and network topology, this 343 adaptation can occur in various forms and at various nodes. As an 344 example, the sender can change the media encoding, or the receiver 345 can change the subscription to a layered encoding, or either reaction 346 can be accomplished by a transcoding middlebox. RFC 5117 identifies 347 seven topologies in which RTP sessions may be configured, and which 348 may affect the ability to use ECN: 350 Topo-Point-to-Point: This is a standard unicast flow. ECN may be 351 used with RTP in this topology in an analogous manner to its use 352 with other unicast transport protocols, with RTCP conveying ECN 353 feedback messages. 355 Topo-Multicast: This is either an any source multicast (ASM) group 356 [RFC3569] with potentially several active senders and multicast 357 RTCP feedback, or a source specific multicast (SSM) group 358 [RFC4607] with a single sender and unicast RTCP feedback from 359 receivers. RTCP is designed to scale to large group sizes while 360 avoiding feedback implosion (see Section 6.2 of [RFC3550], 361 [RFC4585], and [RFC5760]), and can be used by a sender to 362 determine if all its receivers, and the network paths to those 363 receivers, support ECN (see Section 7.2). It is somewhat more 364 difficult to determine if all network paths from all senders to 365 all receivers support ECN. Accordingly, we allow ECN to be used 366 by an RTP sender using multicast UDP provided the sender has 367 verified that the paths to all its known receivers support ECN, 368 and irrespective of whether the paths from other senders to their 369 receivers support ECN ("all its known receivers" are all the SSRCs 370 that the RTP sender has received RTP or RTCP from the last five 371 reporting intervals, i.e., they have not timed out). Note that 372 group membership may change during the lifetime of a multicast RTP 373 session, potentially introducing new receivers that are not ECN 374 capable or have a path that doesn't support ECN. Senders must use 375 the mechanisms described in Section 7.4 to monitor that all 376 receivers continue to support ECN, and they need to fallback to 377 non-ECN use if any senders do not. 379 Topo-Translator: An RTP translator is an RTP-level middlebox that is 380 invisible to the other participants in the RTP session (although 381 it is usually visible in the associated signalling session). 382 There are two types of RTP translator: those that do not modify 383 the media stream, and are concerned with transport parameters, for 384 example a multicast to unicast gateway; and those that do modify 385 the media stream, for example transcoding between different media 386 codecs. A single RTP session traverses the translator, and the 387 translator must rewrite RTCP messages passing through it to match 388 the changes it makes to the RTP data packets. A legacy, ECN- 389 unaware, RTP translator is expected to ignore the ECN bits on 390 received packets, and to set the ECN bits to not-ECT when sending 391 packets, so causing ECN negotiation on the path containing the 392 translator to fail (any new RTP translator that does not wish to 393 support ECN may do so similarly). An ECN aware RTP translator may 394 act in one of three ways: 396 * If the translator does not modify the media stream, it should 397 copy the ECN bits unchanged from the incoming to the outgoing 398 datagrams, unless it is overloaded and experiencing congestion, 399 in which case it may mark the outgoing datagrams with an ECN-CE 400 mark. Such a translator passes RTCP feedback unchanged. See 401 Section 8.1. 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], see Section 8.2 for details. 408 * If the translator is a media transcoder, or otherwise modifies 409 the content of the media stream, the output RTP media stream 410 may have radically different characteristics than the input RTP 411 media stream. Each side of the translator must then be 412 considered as a separate transport connection, with its own ECN 413 processing. This requires the translator interpose itself into 414 the ECN negotiation process, effectively splitting the 415 connection into two parts with their own negotiation. Once 416 negotiation has been completed, the translator must generate 417 RTCP ECN feedback back to the source based on its own 418 reception, and must respond to RTCP ECN feedback received from 419 the receiver(s) (see Section 8.3). 421 It is recognised that ECN and RTCP processing in an RTP translator 422 that modifies the media stream is non-trivial. 424 Topo-Mixer: A mixer is an RTP-level middlebox that aggregates 425 multiple RTP streams, mixing them together to generate a new RTP 426 stream. The mixer is visible to the other participants in the RTP 427 session, and is also usually visible in the associated signalling 428 session. The RTP flows on each side of the mixer are treated 429 independently for ECN purposes, with the mixer generating its own 430 RTCP ECN feedback, and responding to ECN feedback for data it 431 sends. Since unicast transport between the mixer and any end- 432 point are treated independently, it would seem reasonable to allow 433 the transport on one side of the mixer to use ECN, while the 434 transport on the other side of the mixer is not ECN capable, if 435 this is desired. See Section 8.4 for details in how mixers should 436 process ECN. 438 Topo-Video-switch-MCU: A video switching MCU receives several RTP 439 flows, but forwards only one of those flows onwards to the other 440 participants at a time. The flow that is forwarded changes during 441 the session, often based on voice activity. Since only a subset 442 of the RTP packets generated by a sender are forwarded to the 443 receivers, a video switching MCU can break ECN negotiation (the 444 success of the ECN negotiation may depend on the voice activity of 445 the participant at the instant the negotiation takes place - shout 446 if you want ECN). It also breaks congestion feedback and 447 response, since RTP packets are dropped by the MCU depending on 448 voice activity rather than network congestion. This topology is 449 widely used in legacy products, but is NOT RECOMMENDED for new 450 implementations and SHALL NOT be used with ECN. 452 Topo-RTCP-terminating-MCU: In this scenario, each participant runs 453 an RTP point-to-point session between itself and the MCU. Each of 454 these sessions is treated independently for the purposes of ECN 455 and RTCP feedback, potentially with some using ECN and some not. 457 Topo-Asymmetric: It is theoretically possible to build a middlebox 458 that is a combination of an RTP mixer in one direction and an RTP 459 translator in the other. To quote RFC 5117 "This topology is so 460 problematic and it is so easy to get the RTCP processing wrong, 461 that it is NOT RECOMMENDED to implement this topology." 463 These topologies may be combined within a single RTP session. 465 The ECN mechanism defined in this memo is applicable to both sender 466 and receiver controlled congestion algorithms. The mechanism ensures 467 that both senders and receivers will know about ECN-CE markings and 468 any packet losses. Thus the actual decision point for the congestion 469 control is not relevant. This is a great benefit as the rate of an 470 RTP session can be varied in a number of ways, for example a unicast 471 media sender might use TFRC [RFC5348] or some other algorithm, while 472 a multicast session could use a sender based scheme adapting to the 473 lowest common supported rate, or a receiver driven mechanism using 474 layered coding to support more heterogeneous paths. 476 To ensure timely feedback of CE marked packets when needed, this 477 mechanism requires support for the RTP/AVPF profile [RFC4585] or any 478 of its derivatives, such as RTP/SAVPF [RFC5124]. The standard RTP/ 479 AVP profile [RFC3551] does not allow any early or immediate 480 transmission of RTCP feedback, and has a minimal RTCP interval whose 481 default value (5 seconds) is many times the normal RTT between sender 482 and receiver. 484 3.3. Interoperability 486 The interoperability requirements for this specification are that 487 there is at least one common interoperability point for all 488 implementations. Since initialization using RTP and RTCP is the one 489 method that works in all cases, although is not optimal for all 490 usages, it is selected as mandatory to implement this initialisation 491 method. This method requires both the RTCP XR extension and the ECN 492 feedback format, which requires the RTP/AVPF profile to ensure timely 493 feedback. 495 When one considers all the uses of ECN for RTP it is clear that there 496 exist congestion control mechanisms that are receiver driven only 497 (Section 7.3.3). These congestion control mechanism do not require 498 timely feedback of congestion events to the sender. If such a 499 congestion control mechanism is combined with an initialization 500 method that also doesn't require timely feedback using RTCP, like the 501 leap of faith or the ICE based method then neither the ECN feedback 502 format nor the RTP/AVPF profile would appear to be needed. However, 503 fault detection can be greatly improved by using receiver side 504 detection (Section 7.4.1) and early reporting of such cases using the 505 ECN feedback mechanism. 507 For interoperability we mandate the implementation of the RTP/AVPF 508 profile, with both RTCP extensions and the necessary signalling to 509 support a common operations mode. This specification recommends the 510 use of RTP/AVPF in all cases as negotiation of the common 511 interoperability point requires RTP/AVPF, mixed negotiation of RTP/ 512 AVP and RTP/AVPF depending on other SDP attributes in the same media 513 block is difficult, and the fact that fault detection can be improved 514 when using RTP/AVPF. 516 The use of the ECN feedback format is also recommended but cases 517 where its usage is not required due to no need for timely feedback, 518 that will be explicitly noted in the specification text. The term 519 "no timely feedback required" will be used to indicate usage that 520 employs this specification in combination with receiver driven 521 congestion control, and initialization methods that do not require 522 timely feedback, i.e. currently leap of faith and ICE based. We also 523 note that any receiver driven congestion control solution that still 524 requires RTCP for signalling of any adaptation information to the 525 sender will still require RTP/AVPF for timeliness. 527 4. Overview of Use of ECN with RTP/UDP/IP 529 The solution for using ECN with RTP over UDP/IP consists of four 530 different pieces that together make the solution work: 532 1. Negotiation of the capability to use ECN with RTP/UDP/IP 534 2. Initiation and initial verification of ECN capable transport 536 3. Ongoing use of ECN within an RTP session 538 4. Handling of dynamic behavior through failure detection, 539 verification and fallback 541 Before an RTP session can be created, a signalling protocol is used 542 to discover the other participants and negotiate or configure session 543 parameters (see Section 7.1). One of the parameters that must be 544 agreed is the capability of a participant to support ECN. Note that 545 all participants having the capability of supporting ECN does not 546 necessarily imply that ECN is usable in an RTP session, since there 547 may be middleboxes on the path between the participants which don't 548 pass ECN-marked packets (for example, a firewall that blocks traffic 549 with the ECN bits set). This document defines the information that 550 needs to be negotiated, and provides a mapping to SDP for use in both 551 declarative and offer/answer contexts. 553 When a sender joins a session for which all participants claim to 554 support ECN, it must verify if that support is usable. There are 555 three ways in which this verification can be done: 557 o The sender may generate a (small) subset of its RTP data packets 558 with the ECN field set to ECT(0) or ECT(1). Each receiver will 559 then send an RTCP feedback packet indicating the reception of the 560 ECT marked RTP packets. Upon reception of this feedback from each 561 receiver it knows of, the sender can consider ECN functional for 562 its traffic. Each sender does this verification independently. 563 When a new receiver joins an existing RTP session, it will send 564 RTCP reports in the usual manner. If those RTCP reports include 565 ECN information, verification will have succeeded and sources can 566 continue to send ECT packets. If not, verification fails and each 567 sender MUST stop using ECN (see Section 7.2.1 for details). 569 o Alternatively, ECN support can be verified during an initial end- 570 to-end STUN exchange (for example, as part of ICE connection 571 establishment). After having verified connectivity without ECN 572 capability an extra STUN exchange, this time with the ECN field 573 set to ECT(0) or ECT(1), is performed on the candidate path that 574 is about to be used. If successful the path's capability to 575 convey ECN marked packets is verified. A new STUN attribute is 576 defined to convey feedback that the ECT marked STUN request was 577 received (see Section 7.2.2), along with an ICE signalling option 578 (Section 6.4) to indicate that the check is to be performed. 580 o Thirdly, the sender may make a leap of faith that ECN will work. 581 This is only recommended for applications that know they are 582 running in controlled environments where ECN functionality has 583 been verified through other means. In this mode it is assumed 584 that ECN works, and the system reacts to failure indicators if the 585 assumption proved wrong. The use of this method relies on a high 586 confidence that ECN operation will be successful, or an 587 application where failure is not serious. The impact on the 588 network and other users must be considered when making a leap of 589 faith, so there are limitations on when this method is allowed 590 (see Section 7.2.3). 592 The first mechanism, using RTP with RTCP feedback, has the advantage 593 of working for all RTP sessions, but the disadvantages of potential 594 clipping if ECN marked RTP packets are discarded by middleboxes, and 595 slow verification of ECN support. The STUN-based mechanism is faster 596 to verify ECN support, but only works in those scenarios supported by 597 end-to-end STUN, such as within an ICE exchange. The third one, 598 leap-of-faith, has the advantage of avoiding additional tests or 599 complexities and enabling ECN usage from the first media packet. The 600 downside is that if the end-to-end path contains middleboxes that do 601 not pass ECN, the impact on the application can be severe: in the 602 worst case, all media could be lost if a middlebox that discards ECN 603 marked packets is present. A less severe effect, but still requiring 604 reaction, is the presence of a middlebox that re-marks ECT marked 605 packets to non-ECT, possibly marking packets with a CE mark as non- 606 ECT. This could result in increased levels of congestion due to non- 607 responsiveness, and impact media quality as applications end up 608 relying on packet loss as an indication of congestion. 610 Once ECN support has been verified (or assumed) to work for all 611 receivers, a sender marks all its RTP packets as ECT packets, while 612 receivers rapidly feed back reports on any ECN-CE marks to the sender 613 using RTCP in RTP/AVPF immediate or early feedback mode, unless no 614 timely feedback is required. Each feedback report indicates the 615 receipt of new CE marks since the last ECN feedback packet, and also 616 counts the total number of CE marked packets as a cumulative sum. 617 This is the mechanism to provide the fastest possible feedback to 618 senders about CE marks. On receipt of a CE marked packet, the system 619 must react to congestion as-if packet loss has been reported. 620 Section 7.3 describes the ongoing use of ECN within an RTP session. 622 This rapid feedback is not optimised for reliability, so another 623 mechanism, RTCP XR ECN summary reports, is used to ensure more 624 reliable, but less timely, reporting of the ECN information. The ECN 625 summary report contains the same information as the ECN feedback 626 format, only packed differently for better efficiency with reports 627 for many sources. It is sent in a compound RTCP packet, along with 628 regular RTCP reception reports. By using cumulative counters for 629 observed CE, ECT, not-ECT, packet duplication, and packet loss the 630 sender can determine what events have happened since the last report, 631 independently of any RTCP packets having been lost. 633 RTCP reports MUST NOT be ECT marked, since ECT marked traffic may be 634 dropped if the path is not ECN compliant. RTCP is used to provide 635 feedback about what has been transmitted and what ECN markings that 636 are received, so it is important that it is received in cases when 637 ECT marked traffic is not getting through. 639 There are numerous reasons why the path the RTP packets take from the 640 sender to the receiver may change, e.g., mobility, link failure 641 followed by re-routing around it. Such an event may result in the 642 packet being sent through a node that is ECN non-compliant, thus re- 643 marking or dropping packets with ECT set. To prevent this from 644 impacting the application for longer than necessary, the operation of 645 ECN is constantly monitored by all senders (Section 7.4). Both the 646 RTCP XR ECN summary reports and the ECN feedback packets allow the 647 sender to compare the number of ECT(0), ECT(1), and non-ECT marked 648 packets received with the number that were sent, while also reporting 649 CE marked and lost packets. If these numbers do not agree, it can be 650 inferred that the path does not reliably pass ECN-marked packets. A 651 sender detecting a possible ECN non-compliance issue should then stop 652 sending ECT marked packets to determine if that allows the packets to 653 be correctly delivered. If the issues can be connected to ECN, then 654 ECN usage is suspended. 656 5. RTCP Extensions for ECN feedback 658 This memo defines two new RTCP extensions: one RTP/AVPF [RFC4585] 659 transport layer feedback format for urgent ECN information, and one 660 RTCP XR [RFC3611] ECN summary report block type for regular reporting 661 of the ECN marking information. 663 5.1. RTP/AVPF Transport Layer ECN Feedback packet 665 This RTP/AVPF transport layer feedback format is intended for use in 666 RTP/AVPF early or immediate feedback modes when information needs to 667 urgently reach the sender. Thus its main use is to report on 668 reception of an ECN-CE marked RTP packet so that the sender may 669 perform congestion control, or to speed up the initiation procedures 670 by rapidly reporting that the path can support ECN-marked traffic. 671 The feedback format is also defined with reduced size RTCP [RFC5506] 672 in mind, where RTCP feedback packets may be sent without accompanying 673 Sender or Receiver Reports that would contain the Extended Highest 674 Sequence number and the accumulated number of packet losses. Both 675 are important for ECN to verify functionality and keep track of when 676 CE marking does occur. 678 The RTP/AVPF transport layer feedback packet starts with the common 679 header defined by the RTP/AVPF profile [RFC4585] which is reproduced 680 in Figure 1. The FMT field takes the value [TBA1] to indicate that 681 the Feedback Control Information (FCI) contains ECN Feedback report, 682 as defined in Figure 2. 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 |V=2|P| FMT=TBA1| PT=RTPFB=205 | length | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | SSRC of packet sender | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | SSRC of media source | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 : Feedback Control Information (FCI) : 694 : : 696 Figure 1: RTP/AVPF Common Packet Format for Feedback Messages 698 0 1 2 3 699 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 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Extended Highest Sequence Number | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | ECT (0) Counter | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | ECT (1) Counter | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | CE Counter | not-ECT Counter | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Loss Packet Counter | Duplication Counter | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 Figure 2: ECN Feedback Report Format 714 The ECN Feedback Report contains the following fields: 716 Extended Highest Sequence Number: The 32-bit Extended highest 717 sequence number received, as defined by [RFC3550]. Indicates the 718 highest RTP sequence number to which this report relates. 720 ECT(0) Counter: The 32-bit cumulative number of RTP packets with 721 ECT(0) received from this SSRC. 723 ECT(1) Counter: The 32-bit cumulative number of RTP packets with 724 ECT(1) received from this SSRC. 726 CE Counter: The cumulative number of RTP packets received from this 727 SSRC since the receiver joined the RTP session that were ECN-CE 728 marked, including ECN-CE marks in any duplicate packets. The 729 receiver should keep track of this value using a local 730 representation that is at least 32-bits, and only include the 16- 731 bits with least significance. In other words, the field will wrap 732 if more than 65535 packets has been received. 734 not-ECT Counter: The cumulative number of RTP packets received from 735 this SSRC since the receiver joined the RTP session that had an 736 ECN field value of not-ECT. The receiver should keep track of 737 this value using a local representation that is at least 32-bits, 738 and only include the 16-bits with least significance. In other 739 words, the field will wrap if more than 65535 packets have been 740 received. 742 Lost Packets Counter: The cumulative number of RTP packets that the 743 receiver expected to receive minus the number of packets it 744 actually received that are not a duplicate of an already received 745 packet, from this SSRC since the receiver joined the RTP session. 746 Note that packets that arrive late are not counted as lost. The 747 receiver should keep track of this value using a local 748 representation that is at least 32-bits, and only include the 16- 749 bits with least significance. In other words, the field will wrap 750 if more than 65535 packets have been received. 752 Duplication Counter: The cumulative number of RTP packets received 753 that are a duplicate of an already received packet from this SSRC 754 since the receiver joined the RTP session. The receiver should 755 keep track of this value using a local representation that is at 756 least 32-bits, and only include the 16-bits with least 757 significance. In other words, the field will wrap if more than 758 65535 packets have been received. 760 All fields in the ECN Feedback Report are unsigned integers in 761 network byte order. Each ECN Feedback Report corresponds to a single 762 RTP source (SSRC). Multiple sources can be reported by including 763 multiple ECN Feedback Reports packets in an compound RTCP packet. 765 The counters SHALL be initiated to 0 for each new SSRC received. 766 This to enable detection of CE or Packet loss already on the initial 767 report from a specific participant. 769 The usage of at least 32-bit counters allows even extremely high 770 packet volume applications to not have wrapping of counters within 771 any timescale close to the reporting intervals. However, 32-bits are 772 not sufficiently large to disregard the fact that wrappings may 773 happen during the life time of a long-lived RTP session. Thus 774 handling of wrapping of these counters MUST be supported. It is 775 recommended that implementations uses local representation of these 776 counters that are longer than 32-bits to enable easy handling of 777 wraps. 779 There is a difference in packet duplication reports between the 780 packet loss counter that is defined in the Receiver Report Block 781 [RFC3550] and that defined here. To avoid holding state for what RTP 782 sequence numbers have been received, [RFC3550] specifies that one can 783 count packet loss by counting the number of received packets and 784 comparing it to the number of packets expected. As a result a packet 785 duplication can hide a packet loss. However, when populating the ECN 786 Feedback report, a receiver needs to track the sequence numbers 787 actually received and count duplicates and packet loss separately to 788 provide a more reliable indication. Reordering may however still 789 result in that packet loss is reported in one report and then removed 790 in the next. 792 The CE counter is robust for packet duplication. Adding each 793 received CE marked packet to the counter is not an issue, in fact it 794 is required to ensure complete tracking of the ECN state. If one of 795 the clones was CE marked that is still an indication of congestion. 796 Packet duplication has potential impact on the ECN verification and 797 thus there is a need to count the duplicates. 799 5.2. RTCP XR Report block for ECN summary information 801 This unilateral XR report block combined with RTCP SR or RR report 802 blocks carries the same information as the ECN Feedback Report and is 803 be based on the same underlying information. However, the ECN 804 Feedback Report is intended to report on a CE mark as soon as 805 possible, while this extended report is for the regular RTCP 806 reporting and continuous verification of the ECN functionality end- 807 to-end. 809 The ECN Summary report block consists of one RTCP XR report block 810 header, shown in Figure 3 followed by one or more ECN summary report 811 data blocks, as defined in Figure 4. 813 0 1 2 3 814 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 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | BT=[TBA2] | Reserved | Block Length | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 Figure 3: RTCP XR Report Header 821 0 1 2 3 822 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 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | SSRC of Media Sender | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | ECT (0) Counter | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 | ECT (1) Counter | 829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 830 | CE Counter | not-ECT Counter | 831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 | Loss Packet Counter | Duplication Counter | 833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 Figure 4: RTCP XR ECN Summary Report 837 The RTCP XR ECN Summary Report contains the following fields: 839 BT: Block Type identifying the ECN summary report block. Value is 840 [TBA2]. 842 Reserved: All bits SHALL be set to 0 on transmission and ignored on 843 reception. 845 Block Length: The length of the report block. Used to indicate the 846 number of report data blocks present in the ECN summary report. 847 This length will be 5*n, where n is the number of ECN summary 848 report blocks, since blocks are a fixed size. The block length 849 MAY be zero if there is nothing to report. Receivers MUST discard 850 reports where the block length is not a multiple of five octets, 851 since these cannot be valid. 853 SSRC of Media Sender: The SSRC identifying the media sender this 854 report is for. 856 ECT(0) Counter: as in Section 5.1. 858 ECT(1) Counter: as in Section 5.1. 860 CE Counter: as in Section 5.1. 862 not-ECT Counter: as in Section 5.1. 864 Loss Packet Counter: as in Section 5.1. 866 Duplication Counter: as in Section 5.1. 868 The Extended Highest Sequence number counter for each SSRC is not 869 present in RTCP XR report, in contrast to the feedback version. The 870 reason is that this summary report will rely on the information sent 871 in the Sender Report (SR) or Receiver Report (RR) blocks part of the 872 same RTCP compound packet. The Extended Highest Sequence number is 873 available from the SR or RR. 875 All the SSRCs that are present in the SR or RR SHOULD also be 876 included in the RTCP XR ECN summary report. In cases where the 877 number of senders are so large that the combination of SR/RR and the 878 ECN summary for all the senders exceed the MTU, then only a subset of 879 the senders SHOULD be included so that the reports for the subset 880 fits within the MTU. The subsets SHOULD be selected round-robin 881 across multiple intervals so that all sources are periodically 882 reported. In case there are no SSRCs that currently are counted as 883 senders in the session, the report block SHALL still be sent with no 884 report block entry and a zero report block length to continuously 885 indicate to the other participants the receiver capability to report 886 ECN information. 888 6. SDP Signalling Extensions for ECN 890 This section defines a number of SDP signalling extensions used in 891 the negotiation of the ECN for RTP support when using SDP. This 892 includes one SDP attribute "ecn-capable-rtp" that negotiates the 893 actual operation of ECN for RTP. Two SDP signalling parameters are 894 defined to indicate the use of the RTCP XR ECN summary block and the 895 RTP/AVPF feedback format for ECN. One ICE option SDP representation 896 is also defined. 898 6.1. Signalling ECN Capability using SDP 900 One new SDP attribute, "a=ecn-capable-rtp", is defined. This is a 901 media level attribute, and MUST NOT be used at the session level. It 902 is not subject to the character set chosen. The aim of this 903 signalling is to indicate the capability of the sender and receivers 904 support of ECN, and to negotiate the method of ECN initiation to be 905 used in the session. The attribute takes a list of initiation 906 methods, ordered in decreasing preference. The defined values for 907 the initiation method are: 909 rtp: Using RTP and RTCP as defined in Section 7.2.1. 911 ice: Using STUN within ICE as defined in Section 7.2.2. 913 leap: Using the leap of faith method as defined in Section 7.2.3. 915 Further methods may be specified in the future, so unknown methods 916 MUST be ignored upon reception. 918 In addition, a number of OPTIONAL parameters may be included in the 919 "a=ecn-capable-rtp" attribute as follows: 921 mode: This parameter signals the endpoint's capability to set and 922 read ECN marks in UDP packets. An examination of various 923 operating systems has shown that end-system support for ECN 924 marking of UDP packets may be symmetric or asymmetric. By this we 925 mean that some systems may allow end points to set the ECN bits in 926 an outgoing UDP packet but not read them, while others may allow 927 applications to read the ECN bits but not set them. This 928 either/or case may produce an asymmetric support for ECN and thus 929 should be conveyed in the SDP signalling. The "mode=setread" 930 state is the ideal condition where an endpoint can both set and 931 read ECN bits in UDP packets. The "mode=setonly" state indicates 932 that an endpoint can set the ECT bit, but cannot read the ECN bits 933 from received UDP packets to determine if upstream congestion 934 occurred. The "mode=readonly" state indicates that the endpoint 935 can read the ECN bits to determine if congestion has occurred for 936 incoming packets, but it cannot set the ECT bits in outgoing UDP 937 packets. When the "mode=" parameter is omitted it is assumed that 938 the node has "setread" capabilities. This option can provide for 939 an early indication that ECN cannot be used in a session. This 940 would be case when both the offerer and answerer set the "mode=" 941 parameter to "setonly" or "readonly". 943 ect: This parameter makes it possible to express the preferred ECT 944 marking. This is either "random", "0", or "1", with "0" being 945 implied if not specified. The "ect" parameter describes a 946 receiver preference, and is useful in the case where the receiver 947 knows it is behind a link using IP header compression, the 948 efficiency of which would be seriously disrupted if it were to 949 receive packets with randomly chosen ECT marks. It is RECOMMENDED 950 that ECT(0) marking be used. 952 The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp" attribute is 953 shown in Figure 5. 955 ecn-attribute = "a=ecn-capable-rtp:" SP init-list [SP parm-list] 956 init-list = init-value *("," init-value) 957 init-value = "rtp" / "ice" / "leap" / init-ext 958 init-ext = token 959 parm-list = parm-value *(";" SP parm-value) 960 parm-value = mode / ect / parm-ext 961 mode = "mode=" ("setonly" / "setread" / "readonly") 962 ect = "ect=" ("0" / "1" / "random") 963 parm-ext = parm-name "=" parm-value-ext 964 parm-name = token 965 parm-value-ext = token / quoted-string 966 quoted-string = DQUOTE *qdtext DQUOTE 967 qdtext = %x20-21 / %x23-7E / %x80-FF 968 ; any 8-bit ascii except <"> 970 ; external references: 971 ; token: from RFC 4566 972 ; SP and DQUOTE from RFC 5234 974 Figure 5: ABNF Grammar for the "a=ecn-capable-rtp" attribute 976 6.1.1. Use of "a=ecn-capable-rtp:" with the Offer/Answer Model 978 When SDP is used with the offer/answer model [RFC3264], the party 979 generating the SDP offer MUST insert an "a=ecn-capable-rtp" attribute 980 into the media section of the SDP offer of each RTP session for which 981 it wishes to use ECN. The attribute includes one or more ECN 982 initiation methods in a comma separated list in decreasing order of 983 preference, with any number of optional parameters following. The 984 answering party compares the list of initiation methods in the offer 985 with those it supports in order of preference. If there is a match, 986 and if the receiver wishes to attempt to use ECN in the session, it 987 includes an "a=ecn-capable-rtp" attribute containing its single 988 preferred choice of initiation method, and any optional parameters, 989 in the media sections of the answer. If there is no matching 990 initiation method capability, or if the receiver does not wish to 991 attempt to use ECN in the session, it does not include an "a=ecn- 992 capable-rtp" attribute in its answer. If the attribute is removed in 993 the answer then ECN MUST NOT be used in any direction for that media 994 flow. If there are initialization methods that are unknown, they 995 MUST be ignored on reception and MUST NOT be included in an answer. 997 The endpoints' capability to set and read ECN marks, as expressed by 998 the optional "mode=" parameter, determines whether ECN support can be 999 negotiated for flows in one or both directions: 1001 o If the "mode=setonly" parameter is present in the "a=ecn-capable- 1002 rtp" attribute of the offer and the answering party is also 1003 "mode=setonly", then there is no common ECN capability, and the 1004 answer MUST NOT include the "a=ecn-capable-rtp" attribute. 1005 Otherwise, if the offer is "mode=setonly" then ECN may only be 1006 initiated in the direction from the offering party to the 1007 answering party. 1009 o If the "mode=readonly" parameter is present in the "a=ecn-capable- 1010 rtp" attribute of the offer and the answering party is 1011 "mode=readonly", then there is no common ECN capability, and the 1012 answer MUST NOT include the "a=ecn-capable-rtp" attribute. 1013 Otherwise, if the offer is "mode=readonly" then ECN may only be 1014 initiated in the direction from the answering party to the 1015 offering party. 1017 o If the "mode=setread" parameter is present in the "a=ecn-capable- 1018 rtp" attribute of the offer and the answering party is "setonly", 1019 then ECN may only be initiated in the direction from the answering 1020 party to the offering party. If the offering party is 1021 "mode=setread" but the answering party is "mode=readonly", then 1022 ECN may only be initiated in the direction from the offering party 1023 to the answering party. If both offer and answer are 1024 "mode=setread", then ECN may be initiated in both directions. 1025 Note that "mode=setread" is implied by the absence of a "mode=" 1026 parameter in the offer or the answer. 1028 o An offer that does not include a "mode=" parameter MUST be treated 1029 as-if a "mode=setread" parameter had been included. 1031 In an RTP session using multicast and ECN, participants that intend 1032 to send RTP packets SHOULD support setting ECT marks in RTP packets 1033 (i.e., should be "mode=setonly" or "mode=setread"). Participants 1034 receiving data need the capability to read ECN marks on incoming 1035 packets. It is important that receivers can read ECN marks (are 1036 "mode=readonly" or "mode=setread"), since otherwise no sender in the 1037 multicast session will be able to enable ECN. Accordingly, receivers 1038 that are "mode=setonly" SHOULD NOT join multicast RTP sessions that 1039 use ECN. If session participants that are not aware of the ECN for 1040 RTP signalling are invited to a multicast session, and simply ignore 1041 the signalling attribute, the other party in the offer/answer 1042 exchange SHOULD terminate the SDP dialogue so that the participant 1043 leaves the session. 1045 The "ect=" parameter in the "a=ecn-capable-rtp" attribute is set 1046 independently in the offer and the answer. Its value in the offer 1047 indicates a preference for the sending behaviour of the answering 1048 party, and its value in the answer indicates a sending preference for 1049 the behaviour of the offering party. It will be the senders choice 1050 to honour the receivers preference for what to receive or not. In 1051 multicast sessions, all senders SHOULD set the ECT marks using the 1052 value declared in the "ect=" parameter. 1054 Unknown optional parameters MUST be ignored on reception, and MUST 1055 NOT be included in the answer. That way new parameters may be 1056 introduced and verified to be supported by the other end-point by 1057 having them include it in any answer. 1059 6.1.2. Use of "a=ecn-capable-rtp:" with Declarative SDP 1061 When SDP is used in a declarative manner, for example in a multicast 1062 session using the Session Announcement Protocol (SAP, [RFC2974]), 1063 negotiation of session description parameters is not possible. The 1064 "a=ecn-capable-rtp" attribute MAY be added to the session description 1065 to indicate that the sender will use ECN in the RTP session. The 1066 attribute MUST include a single method of initiation. Participants 1067 MUST NOT join such a session unless they have the capability to 1068 receive ECN-marked UDP packets, implement the method of initiation, 1069 and can generate RTCP ECN feedback. The mode parameter MAY also be 1070 included in declarative usage, to indicate the minimal capability is 1071 required by the consumer of the SDP. So for example in a SSM session 1072 the participants configured with a particular SDP will all be in a 1073 media receive only mode, thus mode=readonly will work as the 1074 capability of reporting on the ECN markings in the received is what 1075 is required. However, using "mode=readonly" also in ASM sessions is 1076 reasonable, unless all senders are required to attempt to use ECN for 1077 their outgoing RTP data traffic, in which case the mode needs to be 1078 set to "setread". 1080 The "a=ecn-capable-rtp" attribute MAY be used with RTP media sessions 1081 using UDP/IP transport. It MUST NOT be used for RTP sessions using 1082 TCP, SCTP, or DCCP transport, or for non-RTP sessions. 1084 As described in Section 7.3.3, RTP sessions using ECN require rapid 1085 RTCP ECN feedback, unless timely feedback is not required due to a 1086 receiver driven congestion control. To ensure that the sender can 1087 react to ECN-CE marked packets timely feedback is usually required. 1088 Thus, the use of the Extended RTP Profile for RTCP-Based Feedback 1089 (RTP/AVPF) [RFC4585] or other profile that inherits RTP/AVPF's 1090 signalling rules, MUST be signalled unless timely feedback is not 1091 required. If timely feedback is not required it is still RECOMMENDED 1092 to used RTP/AVPF. The signalling of an RTP/AVPF based profile is 1093 likely to be required even if the preferred method of initialization 1094 and the congestion control does not require timely feedback, as the 1095 common interoperable method is likely to be signalled or the improved 1096 fault reaction is desired. 1098 6.2. RTCP ECN Feedback SDP Parameter 1100 A new "nack" feedback parameter "ecn" is defined to indicate the 1101 usage of the RTCP ECN feedback packet format (Section 5.1). The ABNF 1102 [RFC5234] definition of the SDP parameter extension is: 1104 rtcp-fb-nack-param = 1105 rtcp-fb-nack-param /= ecn-fb-par 1106 ecn-fb-par = SP "ecn" 1108 The offer/answer rules for this SDP feedback parameters are specified 1109 in the RTP/AVPF profile [RFC4585]. 1111 6.3. XR Block ECN SDP Parameter 1113 A new unilateral RTCP XR block for ECN summary information is 1114 specified, thus the XR block SDP signalling also needs to be extended 1115 with a parameter. This is done in the same way as for the other XR 1116 blocks. The XR block SDP attribute as defined in Section 5.1 of the 1117 RTCP XR specification [RFC3611] is defined to be extendible. As no 1118 parameter values are needed for this ECN summary block, this 1119 parameter extension consists of a simple parameter name used to 1120 indicate support and intent to use the XR block. 1122 xr-format = 1123 xr-format /= ecn-summary-par 1124 ecn-summary-par = "ecn-sum" 1126 For SDP declarative and offer/answer usage, see the RTCP XR 1127 specification [RFC3611] and its description of how to handle 1128 unilateral parameters. 1130 6.4. ICE Parameter to Signal ECN Capability 1132 One new ICE [RFC5245] option, "rtp+ecn", is defined. This is used 1133 with the SDP session level "a=ice-options" attribute in an SDP offer 1134 to indicate that the initiator of the ICE exchange has the capability 1135 to support ECN for RTP-over-UDP flows (via "a=ice-options: rtp+ecn"). 1136 The answering party includes this same attribute at the session level 1137 in the SDP answer if it also has the capability, and removes the 1138 attribute if it does not wish to use ECN, or doesn't have the 1139 capability to use ECN. If the ICE initiation method (Section 7.2.2) 1140 actually is going to be used, it is also needs to be explicitly 1141 negotiated using the "a=ecn-capable-rtp" attribute. This ICE option 1142 SHALL be included when the ICE initiation method is offered or 1143 declared in the SDP. 1145 Note: This signalling mechanism is not strictly needed as long as 1146 the STUN ECN testing capability is used within the context of this 1147 document. It may however be useful if the ECN verification 1148 capability is used in additional contexts. 1150 7. Use of ECN with RTP/UDP/IP 1152 In the detailed specification of the behaviour below, the different 1153 functions in the general case will first be discussed. In case 1154 special considerations are needed for middleboxes, multicast usage 1155 etc, those will be specially discussed in related subsections. 1157 7.1. Negotiation of ECN Capability 1159 The first stage of ECN negotiation for RTP-over-UDP is to signal the 1160 capability to use ECN. An RTP system that supports ECN and uses SDP 1161 for its signalling MUST implement the SDP extension to signal ECN 1162 capability as described in Section 6.1, the RTCP ECN feedback SDP 1163 parameter defined in Section 6.2, and the XR Block ECN SDP parameter 1164 defined in Section 6.3. It MAY also implement alternative ECN 1165 capability negotiation schemes, such as the ICE extension described 1166 in Section 6.4. Other signalling systems needs to define the 1167 corresponding signalling parameters to what is defined for SDP. 1169 The "ecn-capable-rtp" SDP attribute MUST always be used when 1170 employing ECN for RTP according to this specification in systems 1171 using SDP. As the RTCP XR ECN summary report is required 1172 independently of the initialization method or congestion control 1173 scheme, the "rtcp-xr" attribute with the "ecn-sum" parameter MUST 1174 also be used. The "rtcp-fb" attribute with the "nack" parameter 1175 "ecn" MUST be used whenever the initialization method or a congestion 1176 control algorithm requiring timely sender side knowledge of received 1177 CE markings. If the congestion control scheme uses additional 1178 signalling they should be indicated as appropriate for those 1179 signalling methods. 1181 7.2. Initiation of ECN Use in an RTP Session 1183 Once the sender and the receiver(s) have agreed that they have the 1184 capability to use ECN within a session, they may attempt to initiate 1185 ECN use. All session participants connected over the same transport 1186 will need to use the same initiation method. RTP mixers or 1187 translators can use different initiation methods to different 1188 participants that are connected over different underlying transports. 1189 The mixer or translator will need to do individual signalling with 1190 each participant and ensure to be consistent with the ECN support in 1191 those cases the mixer or translator does not function as one end- 1192 point for the ECN control loop. 1194 At the start of the RTP session, when the first packets with ECT are 1195 sent, it is important to verify that IP packets with ECN field values 1196 of ECT or ECN-CE will reach their destination(s). There is some risk 1197 that the use of ECN will result in either reset of the ECN field, or 1198 loss of all packets with ECT or ECN-CE markings. If the path between 1199 the sender and the receivers exhibits either of these behaviours one 1200 needs to stop using ECN immediately to protect both the network and 1201 the application. 1203 The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic 1204 at any time. This is to ensure that packet loss due to ECN marking 1205 will not effect the RTCP traffic and the necessary feedback 1206 information it carries. 1208 An RTP system that supports ECN MUST implement the initiation of ECN 1209 using in-band RTP and RTCP described in Section 7.2.1. It MAY also 1210 implement other mechanisms to initiate ECN support, for example the 1211 STUN-based mechanism described in Section 7.2.2, or use the leap of 1212 faith option if the session supports the limitations provided in 1213 Section 7.2.3. If support for both in-band and out-of-band 1214 mechanisms is signalled, the sender SHOULD try ECN negotiation using 1215 STUN with ICE first, and if it fails, fallback to negotiation using 1216 RTP and RTCP ECN feedback. 1218 No matter how ECN usage is initiated, the sender MUST continually 1219 monitor the ability of the network, and all its receivers, to support 1220 ECN, following the mechanisms described in Section 7.4. This is 1221 necessary because path changes or changes in the receiver population 1222 may invalidate the ability of the system to use ECN. 1224 7.2.1. Detection of ECT using RTP and RTCP 1226 The ECN initiation phase using RTP and RTCP to detect if the network 1227 path supports ECN comprises three stages. Firstly, the RTP sender 1228 generates some small fraction of its traffic with ECT marks to act as 1229 probe for ECN support. Then, on receipt of these ECT-marked packets, 1230 the receivers send RTCP ECN feedback packets and RTCP ECN summary 1231 reports to inform the sender that their path supports ECN. Finally, 1232 the RTP sender makes the decision to use ECN or not, based on whether 1233 the paths to all RTP receivers have been verified to support ECN. 1235 Generating ECN Probe Packets: During the ECN initiation phase, an 1236 RTP sender SHALL mark a small fraction of its RTP traffic as ECT, 1237 while leaving the reminder of the packets unmarked. The main 1238 reason for only marking some packets is to maintain usable media 1239 delivery during the ECN initiation phase in those cases where ECN 1240 is not supported by the network path. A secondary reason to send 1241 some not-ECT packets are to ensure that the receivers will send 1242 RTCP reports on this sender, even if all ECT marked packets are 1243 lost in transit. The not-ECT packets also provide a base-line to 1244 compare performance parameters against. A fourth reason for only 1245 probing with a small number of packets is to reduce the risk that 1246 significant numbers of congestion markings might be lost if ECT is 1247 cleared to Not-ECT by an ECN-Reverting Middlebox. Then any 1248 resulting lack of congestion response is likely to have little 1249 damaging affect on others. An RTP sender is RECOMMENDED to send a 1250 minimum of two packets with ECT markings per RTCP reporting 1251 interval. In case a random ECT pattern is intended to be used, at 1252 least one packet with ECT(0) and one with ECT(1) should be sent 1253 per reporting interval, in case a single ECT marking is to be 1254 used, only that ECT value SHOULD be sent. The RTP sender SHALL 1255 continue to send some ECT marked traffic as long as the ECN 1256 initiation phase continues. The sender SHOULD NOT mark all RTP 1257 packets as ECT during the ECN initiation phase. 1259 This memo does not mandate which RTP packets are marked with ECT 1260 during the ECN initiation phase. An implementation should insert 1261 ECT marks in RTP packets in a way that minimises the impact on 1262 media quality if those packets are lost. The choice of packets to 1263 mark is clearly very media dependent, but the use of RTP NO-OP 1264 payloads [I-D.ietf-avt-rtp-no-op], if supported, would be an 1265 appropriate choice. For audio formats, if would make sense for 1266 the sender to mark comfort noise packets or similar. For video 1267 formats, packets containing P- or B-frames, rather than I-frames, 1268 would be an appropriate choice. No matter which RTP packets are 1269 marked, those packets MUST NOT be sent in duplicate with and 1270 without ECT, since their RTP sequence number is used to identify 1271 packets that are received with ECN markings. 1273 Generating RTCP ECN Feedback: If ECN capability has been negotiated 1274 in an RTP session, the receivers in the session MUST listen for 1275 ECT or ECN-CE marked RTP packets, and generate RTCP ECN feedback 1276 packets (Section 5.1) to mark their receipt. An immediate or 1277 early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD 1278 be generated on receipt of the first ECT or ECN-CE marked packet 1279 from a sender that has not previously sent any ECT traffic. Each 1280 regular RTCP report MUST also contain an ECN summary report 1281 (Section 5.2). Reception of subsequent ECN-CE marked packets MUST 1282 result in additional early or immediate ECN feedback packets being 1283 sent unless no timely feedback is required. 1285 Determination of ECN Support: RTP is a group communication protocol, 1286 where members can join and leave the group at any time. This 1287 complicates the ECN initiation phase, since the sender must wait 1288 until it believes the group membership has stabilised before it 1289 can determine if the paths to all receivers support ECN (group 1290 membership changes after the ECN initiation phase has completed 1291 are discussed in Section 7.3). 1293 An RTP sender shall consider the group membership to be stable 1294 after it has been in the session and sending ECT-marked probe 1295 packets for at least three RTCP reporting intervals (i.e., after 1296 sending its third regularly scheduled RTCP packet), and when a 1297 complete RTCP reporting interval has passed without changes to the 1298 group membership. ECN initiation is considered successful when 1299 the group membership is stable, and all known participants have 1300 sent one or more RTCP ECN feedback packets or RTCP XR ECN summary 1301 reports indicating correct receipt of the ECT-marked RTP packets 1302 generated by the sender. 1304 As an optimisation, if an RTP sender is initiating ECN usage 1305 towards a unicast address, then it MAY treat the ECN initiation as 1306 provisionally successful if it receives an RTCP ECN feedback 1307 report or an RTCP XR ECN summary report indicating successful 1308 receipt of the ECT-marked packets, with no negative indications, 1309 from a single RTP receiver (where a single RTP receiver is 1310 considered as all SSRCs used by a single RTCP CNAME). After 1311 declaring provisional success, the sender MAY generate ECT-marked 1312 packets as described in Section 7.3, provided it continues to 1313 monitor the RTCP reports for a period of three RTCP reporting 1314 intervals from the time the ECN initiation started, to check if 1315 there are any other participants in the session. Thus as long as 1316 any additional SSRC that report on the ECN usage are using the 1317 same CNAME as the previous reports and they are all indicating 1318 functional ECN the sender may continue. If other participants are 1319 detected, i.e., other CNAMEs, the sender MUST fallback to only 1320 ECT-marking a small fraction of its RTP packets, while it 1321 determines if ECN can be supported following the full procedure 1322 described above. Different CNAMEs received over an unicast 1323 transport may occur when using translators in a multi-party RTP 1324 session (e.g., when using a centralised conference bridge). 1326 Note: The above optimization supports peer to peer unicast 1327 transport with several SSRCs multiplexed onto the same flow 1328 (e.g., SSRC multiplexed RTP retransmission [RFC4588]). It is 1329 desirable to be able to rapidly negotiate ECN support for such 1330 a session, but the optimisation above can fail if there are 1331 implementations that use the same CNAME for different parts of 1332 a distributed implementation that have different transport 1333 characteristics (e.g., if a single logical endpoint is split 1334 across multiple hosts). 1336 ECN initiation is considered to have failed at the instant when 1337 any RTP session participant sends an RTCP packet that doesn't 1338 contain an RTCP ECN feedback report or ECN summary report, but has 1339 an RTCP RR with an extended RTP sequence number field that 1340 indicates that it should have received multiple (>3) ECT marked 1341 RTP packets. This can be due to failure to support the ECN 1342 feedback format by the receiver or some middlebox, or the loss of 1343 all ECT marked packets. Both indicate a lack of ECN support. 1345 If the ECN negotiation succeeds, this indicates that the path can 1346 pass some ECN-marked traffic, and that the receivers support ECN 1347 feedback. This does not necessarily imply that the path can robustly 1348 convey ECN feedback; Section 7.3 describes the ongoing monitoring 1349 that must be performed to ensure the path continues to robustly 1350 support ECN. 1352 When a sender or receiver detects ECN failures on paths they should 1353 log these to enable follow up and statistics gathering regarding 1354 broken paths. The logging mechanism used is implementation 1355 dependent. 1357 7.2.2. Detection of ECT using STUN with ICE 1359 This section describes an OPTIONAL method that can be used to avoid 1360 media impact and also ensure an ECN capable path prior to media 1361 transmission. This method is considered in the context where the 1362 session participants are using ICE [RFC5245] to find working 1363 connectivity. We need to use ICE rather than STUN only, as the 1364 verification needs to happen from the media sender to the address and 1365 port on which the receiver is listening. 1367 Note that this method is only applicable to sessions when the remote 1368 destinations are unicast addresses. In addition transport 1369 translators that do not terminate the ECN control loop and may 1370 distribute received packets to more than one other receiver needs to 1371 either not allow this method (use the RTP/RTCP method instead) or 1372 implement additional handling for this case as discussed below. This 1373 is because the ICE initialization method verifies the underlying 1374 transport to one particular address and port. If the receiver at 1375 that address and port intends to use the received packets in a multi- 1376 point session then the tested capabilities and the actual session 1377 behavior are not matched. 1379 To minimise the impact of set-up delay, and to prioritise the fact 1380 that one has a working connectivity rather than necessarily finding 1381 the best ECN capable network path, this procedure is applied after 1382 having performed a successful connectivity check for a candidate, 1383 which is nominated for usage. At that point an additional 1384 connectivity check is performed, sending the "ECN Check" attribute in 1385 a STUN packet that is ECT marked. On reception of the packet, a STUN 1386 server supporting this extension will note the received ECN field 1387 value, and send a STUN/UDP/IP packet in reply with the ECN field set 1388 to not-ECT and including an ECN check attribute. A STUN server that 1389 doesn't understand the extension, or is incapable of reading the ECN 1390 values on incoming STUN packets, should follow the rule in the STUN 1391 specification for unknown comprehension-optional attributes, and 1392 ignore the attribute, resulting in the sender receiving a STUN 1393 response without the ECN Check STUN attribute. 1395 The STUN ECN check attribute contains one field and a flag, as shown 1396 in Figure 6. The flag indicates whether the echo field contains a 1397 valid value or not. The field is the ECN echo field, and when valid 1398 contains the two ECN bits from the packet it echoes back. The ECN 1399 check attribute is a comprehension optional attribute. 1401 0 1 2 3 1402 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 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | Type | Length | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | Reserved |ECF|V| 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 Figure 6: ECN Check STUN Attribute 1411 V: Valid (1 bit) ECN Echo value field is valid when set to 1, and 1412 invalid when set 0. 1414 ECF: ECN Echo value field (2 bits) contains the ECN field value of 1415 the STUN packet it echoes back when field is valid. If invalid 1416 the content is arbitrary. 1418 Reserved: Reserved bits (29 bits) SHALL be set to 0 on transmission, 1419 and SHALL be ignored on reception. 1421 This attribute MAY be included in any STUN request to request the ECN 1422 field to be echoed back. In STUN requests the V bit SHALL be set to 1423 0. A compliant STUN server receiving a request with the ECN Check 1424 attribute SHALL read the ECN field value of the IP/UDP packet the 1425 request was received in. Upon forming the response the server SHALL 1426 include the ECN Check attribute setting the V bit to valid and 1427 include the read value of the ECN field into the ECF field. If the 1428 STUN responder was unable to ascertain, due to temporary errors, the 1429 ECN value of the STUN request, it SHALL set the V bit in the response 1430 to 0. The STUN client may retry immediately. 1432 The ICE based initialization method does require some special 1433 consideration when used by a translator. This is especially for 1434 transport translators and translators that fragments or reassembles 1435 packets as they do not separate the ECN control loops between the 1436 end-points and the translator. Such a translator that uses ICE based 1437 initialization needs to ensure that any participants joining an RTP 1438 session for which ECN has been negotiated are successfully verified 1439 in the direction from the translator to the joining participant or 1440 correctly handles remarking of ECT RTP packets towards that 1441 participant. When a new participant joins the session, the 1442 translator will perform a check towards the new participant. If that 1443 is successfully completed the ECT properties of the session are 1444 maintained for the other senders in the session. If the check fails 1445 then the existing senders will now see a participant that fails to 1446 receive ECT. Thus the failure detection in those senders will 1447 eventually detect this. However to avoid misusing the network on the 1448 path from the translator to the new participant, the translator SHALL 1449 remark the traffic intended to be forwarded from ECT to non-ECT. Any 1450 packet intended to be forward that are ECN-CE marked SHALL be discard 1451 and not sent. In cases where the path from a new participant to the 1452 translator fails the ECT check then only that sender will not 1453 contribute any ECT marked traffic towards the translator. 1455 7.2.3. Leap of Faith ECT initiation method 1457 This method for initiating ECN usage is a leap of faith that assumes 1458 that ECN will work on the used path(s). The method is to go directly 1459 to "ongoing use of ECN" as defined in Section 7.3. Thus all RTP 1460 packets MAY be marked as ECT and the failure detection MUST be used 1461 to detect any case when the assumption that the path was ECT capable 1462 is wrong. This method is only recommended for controlled 1463 environments where the whole path(s) between sender and receiver(s) 1464 has been built and verified to be ECT. 1466 If the sender marks all packets as ECT while transmitting on a path 1467 that contains an ECN-blocking middlebox, then receivers downstream of 1468 that middlebox will not receive any RTP data packets from the sender, 1469 and hence will not consider it to be an active RTP SSRC. The sender 1470 can detect this and revert to sending packets without ECT marks, 1471 since RTCP SR/RR packets from such receivers will either not include 1472 a report for sender's SSRC, or will report that no packets have been 1473 received, but this takes at least one RTCP reporting interval. It 1474 should be noted that a receiver might generate its first RTCP packet 1475 immediately on joining a unicast session, or very shortly after 1476 joining a RTP/AVPF session, before it has had chance to receive any 1477 data packets. A sender that receives RTCP SR/RR packet indicating 1478 lack of reception by a receiver SHOULD therefore wait for a second 1479 RTCP report from that receiver to be sure that the lack of reception 1480 is due to ECT-marking. Since this recovery process can take several 1481 tens of seconds, during which time the RTP session is unusable for 1482 media, it is NOT RECOMMENDED that the leap-of-faith ECT initiation 1483 method be used in environments where ECN-blocking middleboxes are 1484 likely to be present. 1486 7.3. Ongoing Use of ECN Within an RTP Session 1488 Once ECN usage has been successfully initiated for an RTP sender, 1489 that sender begins sending all RTP data packets as ECT-marked, and 1490 its receivers continue sending ECN feedback information via RTCP 1491 packets. This section describes procedures for sending ECT-marked 1492 data, providing ECN feedback information via RTCP, responding to ECN 1493 feedback information, and detecting failures and misbehaving 1494 receivers. 1496 7.3.1. Transmission of ECT-marked RTP Packets 1498 After a sender has successfully initiated ECN usage, it SHOULD mark 1499 all the RTP data packets it sends as ECT. The sender SHOULD mark 1500 packets as ECT(0) unless the receiver expresses a preference for 1501 ECT(1) or random using the "ect" parameter in the "a=ecn-capable-rtp" 1502 attribute. 1504 The sender SHALL NOT include ECT marks on outgoing RTCP packets, and 1505 SHOULD NOT include ECT marks on any other outgoing control messages 1506 (e.g., STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or 1507 ZRTP [RFC6189] control packets) that are multiplexed on the same UDP 1508 port. For control packets there might be exceptions, like the STUN 1509 based ECN check defined in Section 7.2.2. 1511 7.3.2. Reporting ECN Feedback via RTCP 1513 An RTP receiver that receives a packet with an ECN-CE mark, or that 1514 detects a packet loss, MUST schedule the transmission of an RTCP ECN 1515 feedback packet as soon as possible (subject to the constraints of 1516 [RFC4585] and [RFC3550]) to report this back to the sender unless no 1517 timely feedback required. There should be no difference in behavior 1518 if ECN-CE marks or packet drops are detected. The feedback RTCP 1519 packet sent SHALL consist of at least one ECN feedback packet 1520 (Section 5.1) reporting on the packets received since the last ECN 1521 feedback packet, and will contain an RTCP SR or RR packet unless 1522 reduced size RTCP [RFC5506] is used. The RTP/AVPF profile in early 1523 or immediate feedback mode SHOULD be used where possible, to reduce 1524 the interval before feedback can be sent. To reduce the size of the 1525 feedback message, reduced size RTCP [RFC5506] MAY be used if 1526 supported by the end-points. Both RTP/AVPF and reduced size RTCP 1527 MUST be negotiated in the session set-up signalling before they can 1528 be used. 1530 Every time a regular compound RTCP packet is to be transmitted, an 1531 ECN-capable RTP receiver MUST include an RTCP XR ECN summary report 1532 as described in Section 5.2 as part of the compound packet. 1534 The multicast feedback implosion problem, that occurs when many 1535 receivers simultaneously send feedback to a single sender, must be 1536 considered. The RTP/AVPF transmission rules will limit the amount of 1537 feedback that can be sent, avoiding the implosion problem but also 1538 delaying feedback by varying degrees from nothing up to a full RTCP 1539 reporting interval. As a result, the full extent of a congestion 1540 situation may take some time to reach the sender, although some 1541 feedback should arrive in a reasonably timely manner, allowing the 1542 sender to react on a single or a few reports. 1544 7.3.3. Response to Congestion Notifications 1546 The reception of RTP packets with ECN-CE marks in the IP header are a 1547 notification that congestion is being experienced. The default 1548 reaction on the reception of these ECN-CE marked packets MUST be to 1549 provide the congestion control algorithm with a congestion 1550 notification, that triggers the algorithm to react as if packet loss 1551 had occurred. 1553 We note that there MAY be other reactions to ECN-CE specified in the 1554 future. Such an alternative reaction MUST be specified and 1555 considered to be safe for deployment under any restrictions 1556 specified. A potential example for an alternative reaction could be 1557 emergency communications (such as that generated by first responders, 1558 as opposed to the general public) in networks where the user has been 1559 authorized. A more detailed description of these other reactions, as 1560 well as the types of congestion control algorithms used by end-nodes, 1561 is outside of the scope of this document. 1563 Depending on the media format, type of session, and RTP topology 1564 used, there are several different types of congestion control that 1565 can be used: 1567 Sender-Driven Congestion Control: The sender is responsible for 1568 adapting the transmitted bit-rate in response to RTCP ECN 1569 feedback. When the sender receives the ECN feedback data it feeds 1570 this information into its congestion control or bit-rate 1571 adaptation mechanism so that it can react to it as if packet loss 1572 was reported. The congestion control algorithm to be used is not 1573 specified here, although TFRC [RFC5348] is one example that might 1574 be used. 1576 Receiver-Driven Congestion Control: If a receiver driven congestion 1577 control mechanism is used, the receiver can react to the ECN-CE 1578 marks without contacting the sender. This may allow faster 1579 response than sender-driven congestion control in some 1580 circumstances. Receiver-driven congestion control is usually 1581 implemented by providing the content in a layered way, with each 1582 layer providing improved media quality but also increased 1583 bandwidth usage. The receiver locally monitors the ECN-CE marks 1584 on received packets to check if it experiences congestion with the 1585 current number of layers. If congestion is experienced, the 1586 receiver drops one layer, so reducing the resource consumption on 1587 the path towards itself. For example, if a layered media encoding 1588 scheme such as H.264 SVC is used, the receiver may change its 1589 layer subscription, and so reduce the bit rate it receives. The 1590 receiver MUST still send RTCP XR ECN Summary to the sender, even 1591 if it can adapt without contact with the sender, so that the 1592 sender can determine if ECN is supported on the network path. The 1593 timeliness of RTCP feedback is less of a concern with receiver 1594 driven congestion control, and regular RTCP reporting of ECN 1595 summary information is sufficient (without using RTP/AVPF 1596 immediate or early feedback). 1598 Hybrid: There might be mechanisms that utilize both some receiver 1599 behaviors and some sender side monitoring, thus requiring both 1600 feedback of congestion events to the sender and taking receiver 1601 decisions and possible signalling to the sender. In this case the 1602 congestion control algorithm needs to use the signalling to 1603 indicate which features of ECN for RTP are required. 1605 Responding to congestion indication in the case of multicast traffic 1606 is a more complex problem than for unicast traffic. The fundamental 1607 problem is diverse paths, i.e., when different receivers don't see 1608 the same path, and thus have different bottlenecks, so the receivers 1609 may get ECN-CE marked packets due to congestion at different points 1610 in the network. This is problematic for sender driven congestion 1611 control, since when receivers are heterogeneous in regards to 1612 capacity the sender is limited to transmitting at the rate the 1613 slowest receiver can support. This often becomes a significant 1614 limitation as group size grows. Also, as group size increases the 1615 frequency of reports from each receiver decreases, which further 1616 reduces the responsiveness of the mechanism. Receiver-driven 1617 congestion control has the advantage that each receiver can choose 1618 the appropriate rate for its network path, rather than all having to 1619 settle for the lowest common rate. 1621 We note that ECN support is not a silver bullet to improving 1622 performance. The use of ECN gives the chance to respond to 1623 congestion before packets are dropped in the network, improving the 1624 user experience by allowing the RTP application to control how the 1625 quality is reduced. An application which ignores ECN Congestion 1626 Experienced feedback is not immune to congestion: the network will 1627 eventually begin to discard packets if traffic doesn't respond. It 1628 is in the best interest of an application to respond to ECN 1629 congestion feedback promptly, to avoid packet loss. 1631 7.4. Detecting Failures 1633 Senders and receivers can deliberately ignore ECN-CE and thus get a 1634 benefit over behaving flows (cheating). Th ECN Nonce [RFC3540] is an 1635 addition to TCP that attempts to solve this issue as long as the 1636 sender acts on behalf of the network. The assumption about the 1637 senders acting on the behalf of the network may be reduced due to the 1638 nature of peer-to-peer use of RTP. Still a significant portion of 1639 RTP senders are infrastructure devices (for example, streaming media 1640 servers) that do have an interest in protecting both service quality 1641 and the network. Even though there may be cases where nonce can be 1642 applicable also for RTP, it is not included in this specification. 1643 This as a receiver interested in cheating would simple claim to not 1644 support nonce, or even ECN itself. It is however worth mentioning 1645 that, as real-time media is commonly sensitive to increased delay and 1646 packet loss, it will be in both the media sender and receivers 1647 interest to minimise the number and duration of any congestion events 1648 as they will adversely affect media quality. 1650 RTP sessions can also suffer from path changes resulting in a non-ECN 1651 compliant node becoming part of the path. That node may perform 1652 either of two actions that has effect on the ECN and application 1653 functionality. The gravest is if the node drops packets with the ECN 1654 field set to ECT(0), ECT(1), or CE. This can be detected by the 1655 receiver when it receives an RTCP SR packet indicating that a sender 1656 has sent a number of packets that it has not received. The sender 1657 may also detect it based on the receivers RTCP RR packet where the 1658 extended sequence number is not advanced due to the failure to 1659 receive packets. If the packet loss is less than 100% then packet 1660 loss reporting in either the ECN feedback information or RTCP RR will 1661 indicate the situation. The other action is to re-mark a packet from 1662 ECT or CE to not-ECT. That has less dire results, however, it should 1663 be detected so that ECN usage can be suspended to prevent misusing 1664 the network. 1666 The RTCP XR ECN summary packet and the ECN feedback packet allow the 1667 sender to compare the number of ECT marked packets of different types 1668 received with the number it actually sent. The number of ECT packets 1669 received plus the number of CE marked and lost packets should 1670 correspond to the number of sent ECT marked packets plus the number 1671 of received duplicates. If these numbers doesn't agree there are two 1672 likely reasons, a translator changing the stream or not carrying the 1673 ECN markings forward, or that some node re-marks the packets. In 1674 both cases the usage of ECN is broken on the path. By tracking all 1675 the different possible ECN field values a sender can quickly detect 1676 if some non-compliant behavior is happing on the path. 1678 Thus packet losses and non-matching ECN field value statistics are 1679 possible indication of issues with using ECN over the path. The next 1680 section defines both sender and receiver reactions to these cases. 1682 7.4.1. Fallback mechanisms 1684 Upon the detection of a potential failure both the sender and the 1685 receiver can react to mitigate the situation. 1687 A receiver that detects a packet loss burst MAY schedule an early 1688 feedback packet that includes at least the RTCP RR and the ECN 1689 feedback message to report this to the sender. This will speed up 1690 the detection at the sender of the losses and thus triggering sender 1691 side mitigation. 1693 A sender that detects high packet loss rates for ECT-marked packets 1694 SHOULD immediately switch to sending packets as not-ECT to determine 1695 if the losses potentially are due to the ECT markings. If the losses 1696 disappear when the ECT-marking is discontinued, the RTP sender should 1697 go back to initiation procedures to attempt to verify the apparent 1698 loss of ECN capability of the used path. If a re-initiation fails 1699 then the two possible actions exist: 1701 1. Periodically retry the ECN initiation to detect if a path change 1702 occurs to a path that is ECN capable. 1704 2. Renegotiating the session to disable ECN support. This is a 1705 choice that is suitable if the impact of ECT probing on the media 1706 quality are noticeable. If multiple initiations has been 1707 successful but the following full usage of ECN has resulted in 1708 the fallback procedures then disabling of the ECN support is 1709 RECOMMENDED. 1711 We foresee the possibility of flapping ECN capability due to several 1712 reasons: video switching MCU or similar middleboxes that selects to 1713 deliver media from the sender only intermittently; load balancing 1714 devices may in worst case result in that some packets take a 1715 different network path then the others; mobility solutions that 1716 switch underlying network path in a transparent way for the sender or 1717 receiver; and membership changes in a multicast group. It is however 1718 appropriate to mention that there are also issues such as re-routing 1719 of traffic due to a flappy route table or excessive reordering and 1720 other issues that are not directly ECN related but nevertheless may 1721 cause problems for ECN. 1723 7.4.2. Interpretation of ECN Summary information 1725 This section contains discussion on how you can use the ECN summary 1726 report information in detecting various types of ECN path issues. 1727 Lets start to review the information the reports provide on a per 1728 source (SSRC) basis: 1730 CE Counter: The number of RTP packets received so far in the session 1731 with an ECN field set to CE. 1733 ECT (0/1) Counters: The number of RTP packets received so far in the 1734 session with an ECN field set to ECT (0) and ECT (1) respectively. 1736 not-ECT Counter: The number of RTP packets received so far in the 1737 session with an ECN field set to not-ECT. 1739 Lost Packets counter: The number of RTP packets. that where expected 1740 based on sequence numbers but never received. 1742 Duplication Counter: The number of received RTP packets that are 1743 duplicates of already received ones. 1745 Extended Highest Sequence number: The highest sequence number seen 1746 when sending this report, but with additional bits, to handle 1747 disambiguation when wrapping the RTP sequence number field. 1749 The counters will be initiated to zero to provide value for the RTP 1750 stream sender from the very first report. After the first report the 1751 changes between the latest received and the previous one is 1752 determined by simply taking the values of the latest minus the 1753 previous one, taking field wrapping into account. This definition is 1754 also robust to packet losses, since if one report is missing, the 1755 reporting interval becomes longer, but is otherwise equally valid. 1757 In a perfect world the number of not-ECT packets received should be 1758 equal to the number sent minus the lost packets counter, and the sum 1759 of the ECT(0), ECT(1), and CE counters should be equal to the number 1760 of ECT marked packet sent. Two issues may cause a mismatch in these 1761 statistics: severe network congestion or unresponsive congestion 1762 control might cause some ECT-marked packets to be lost, and packet 1763 duplication might result in some packets being received, and counted 1764 in the statistics, multiple times (potentially with a different ECN- 1765 mark on each copy of the duplicate). 1767 The rate of duplication is tracked, allowing one to take the 1768 duplication into account. The value of the ECN field for duplicates 1769 will also be counted and when comparing the figures one needs to take 1770 some fraction of packet duplicates that are non-ECT and some fraction 1771 of packet duplicates being ECT into account into the calculation. 1772 Thus when only sending non-ECT then the number of sent packets plus 1773 reported duplicates equals the number of received non-ECT. When 1774 sending only ECT then number of sent ECT packets plus duplicates will 1775 equal ECT(0), ECT(1), CE and packet loss. When sending a mix of non- 1776 ECT and ECT then there is an uncertainty if any duplicate or packet 1777 loss was an non-ECT or ECT. If the packet duplication is completely 1778 independent of the usage of ECN, then the fraction of packet 1779 duplicates should be in relation to the number of non-ECT vs ECT 1780 packet sent during the period of comparison. This relation does not 1781 hold for packet loss, where higher rates of packet loss for non-ECT 1782 is expected than for ECT traffic. More on packet loss below. 1784 Detecting clearing of ECN field: If the ratio between ECT and not-ECT 1785 transmitted in the reports has become all not-ECT or substantially 1786 changed towards not-ECT then this is clearly indication that the path 1787 results in clearing of the ECT field. 1789 Dropping of ECT packets: To determine if the packet drop ratio is 1790 different between not-ECT and ECT marked transmission requires a mix 1791 of transmitted traffic. The sender should compare if the delivery 1792 percentage (delivered / transmitted) between ECT and not-ECT is 1793 significantly different. Care must be taken if the number of packets 1794 are low in either of the categories. One must also take into account 1795 the level of CE marking. A CE marked packet would have been dropped 1796 unless it was ECT marked. Thus, the packet loss level for not-ECT 1797 should be approximately equal to the loss rate for ECT when counting 1798 the CE marked packets as lost ones. A sender performing this 1799 calculation needs to ensure that the difference is statistically 1800 significant. 1802 If erroneous behavior is detected, it should be logged to enable 1803 follow up and statistics gathering. 1805 8. Processing ECN in RTP Translators and Mixers 1807 RTP translators and mixers that support ECN for RTP are required to 1808 process, and potentially modify or generate ECN marking in RTP 1809 packets. They also need to process, and potentially modify or 1810 generate RTCP ECN feedback packets for the translated and/or mixed 1811 streams. This includes both downstream RTCP reports generated by the 1812 media sender, and also reports generated by the receivers, flowing 1813 upstream back towards the sender. 1815 8.1. Transport Translators 1817 Some translators only perform transport level translations, like 1818 copying packets from one address domain, like unicast to multicast. 1819 It may also perform relaying like copying an incoming packet to a 1820 number of unicast receivers. This section details the ECN related 1821 actions for RTP and RTCP. 1823 For the RTP data packets the translator, which does not modify the 1824 media stream, SHOULD copy the ECN bits unchanged from the incoming to 1825 the outgoing datagrams, unless the translator itself is overloaded 1826 and experiencing congestion, in which case it may mark the outgoing 1827 datagrams with an ECN-CE mark. 1829 A Transport translator does not modify RTCP packets. It however MUST 1830 perform the corresponding transport translation of the RTCP packets 1831 as it does with RTP packets being sent from the same source/ 1832 end-point. 1834 8.2. Fragmentation and Reassembly in Translators 1836 An RTP translator may fragment or reassemble RTP data packets without 1837 changing the media encoding, and without reference to the congestion 1838 state of the networks it bridges. An example of this might be to 1839 combine packets of a voice-over-IP stream coded with one 20ms frame 1840 per RTP packet into new RTP packets with two 20ms frames per packet, 1841 thereby reducing the header overheads and so stream bandwidth, at the 1842 expense of an increase in latency. If multiple data packets are re- 1843 encoded into one, or vice versa, the RTP translator MUST assign new 1844 sequence numbers to the outgoing packets. Losses in the incoming RTP 1845 packet stream may also induce corresponding gaps in the outgoing RTP 1846 sequence numbers. An RTP translator MUST rewrite RTCP packets to 1847 make the corresponding changes to their sequence numbers, and to 1848 reflect the impact of the fragmentation or reassembly. This section 1849 describes how that rewriting is to be done for RTCP ECN feedback 1850 packets. Section 7.2 of [RFC3550] describes general procedures for 1851 other RTCP packet types. 1853 The processing of arriving RTP packets for this case is as follows. 1854 If an ECN marked packet is split into two, then both the outgoing 1855 packets MUST be ECN marked identically to the original; if several 1856 ECN marked packets are combined into one, the outgoing packet MUST be 1857 either ECN-CE marked or dropped if any of the incoming packets are 1858 ECN-CE marked. If the outgoing combined packet is not ECN-CE marked, 1859 then it MUST be ECT marked if any of the incoming packets were ECT 1860 marked. 1862 RTCP ECN feedback packets (Section 5.1) contain seven fields that are 1863 rewritten in an RTP translator that fragments or reassembles packets: 1864 the extended highest sequence number, the duplication counter, the 1865 lost packets counter, the CE counter, and not-ECT counter, the ECT(0) 1866 counter, and the ECT(1) counter. The RTCP XR report block for ECN 1867 summary information (Section 5.2) includes all of these fields except 1868 the extended highest sequence number which is present in the report 1869 block in an SR or RR packet. The procedures for rewriting these 1870 fields are the same for both RTCP ECN feedback packet and the XR ECN 1871 summary packet. 1873 When receiving an RTCP ECN feedback packet for the translated stream, 1874 an RTP translator first determines the range of packets to which the 1875 report corresponds. The extended highest sequence number in the RTCP 1876 ECN feedback packet (or in the RTCP SR/RR packet contained within the 1877 compound packet, in the case of RTCP XR ECN summary reports) 1878 specifies the end sequence number of the range. For the first RTCP 1879 ECN feedback packet received, the initial extended sequence number of 1880 the range may be determined by subtracting the sum of the lost 1881 packets counter, the CE counter, the not-ECT counter, the ECT(0) 1882 counter and the ECT(1) counter minus the duplication counter, from 1883 the extended highest sequence number. For subsequent RTCP ECN 1884 feedback packets, the starting sequence number may be determined as 1885 being one after the extended highest sequence number of the previous 1886 RTCP ECN feedback packet received from the same SSRC. These values 1887 are in the sequence number space of the translated packets. 1889 Based on its knowledge of the translation process, the translator 1890 determines the sequence number range for the corresponding original, 1891 pre-translation, packets. The extended highest sequence number in 1892 the RTCP ECN feedback packet is rewritten to match the final sequence 1893 number in the pre-translation sequence number range. 1895 The translator then determines the ratio, R, of the number of packets 1896 in the translated sequence number space (numTrans) to the number of 1897 packets in the pre-translation sequence number space (numOrig) such 1898 that R = numTrans / numOrig. The counter values in the RTCP ECN 1899 feedback report are then scaled by dividing each of them by R. For 1900 example, if the translation process combines two RTP packets into 1901 one, then numOrig will be twice numTrans, giving R=0.5, and the 1902 counters in the translated RTCP ECN feedback packet will be twice 1903 those in the original. 1905 The ratio, R, may have a value that leads to non-integer multiples of 1906 the counters when translating the RTCP packet. For example, a VoIP 1907 translator that combines two adjacent RTP packets into one if they 1908 contain active speech data, but passes comfort noise packets 1909 unchanged, would have an R values of between 0.5 and 1.0 depending on 1910 the amount of active speech. Since the counter values in the 1911 translated RTCP report are integer values, rounding will be necessary 1912 in this case. 1914 When rounding counter values in the translated RTCP packet, the 1915 translator should try to ensure that they sum to the number of RTP 1916 packets in the pre-translation sequence number space (numOrig). The 1917 translator should also try to ensure that no non-zero counter is 1918 rounded to a zero value, since that will lose information that a 1919 particular type of event has occurred. It is recognised that it may 1920 be impossible to satisfy both of these constraints; in such cases, it 1921 is better to ensure that no non-zero counter is mapped to a zero 1922 value, since this preserves congestion adaptation and helps the RTCP- 1923 based ECN initiation process. 1925 One should be aware of the impact this type of translators have on 1926 the measurement of packet duplication. A translator performing 1927 aggregation and most likely also an fragmenting translator will 1928 suppress any duplication happening prior to itself. Thus the reports 1929 and what is being scaled will only represent packet duplication 1930 happening from the translator to the receiver reporting on the flow. 1932 It should be noted that scaling the RTCP counter values in this way 1933 is meaningful only on the assumption that the level of congestion in 1934 the network is related to the number of packets being sent. This is 1935 likely to be a reasonable assumption in the type of environment where 1936 RTP translators that fragment or reassemble packets are deployed, as 1937 their entire purpose is to change the number of packets being sent to 1938 adapt to known limitations of the network, but is not necessarily 1939 valid in general. 1941 The rewritten RTCP ECN feedback report is sent from the other side of 1942 the translator to that which it arrived (as part of a compound RTCP 1943 packet containing other translated RTCP packets, where appropriate). 1945 8.3. Generating RTCP ECN Feedback in Media Transcoders 1947 An RTP translator that acts as a media transcoder cannot directly 1948 forward RTCP packets corresponding to the transcoded stream, since 1949 those packets will relate to the non-transcoded stream, and will not 1950 be useful in relation to the transcoded RTP flow. Such a transcoder 1951 will need to interpose itself into the RTCP flow, acting as a proxy 1952 for the receiver to generate RTCP feedback in the direction of the 1953 sender relating to the pre-transcoded stream, and acting in place of 1954 the sender to generate RTCP relating to the transcoded stream, to be 1955 sent towards the receiver. This section describes how this proxying 1956 is to be done for RTCP ECN feedback packets. Section 7.2 of 1957 [RFC3550] describes general procedures for other RTCP packet types. 1959 An RTP translator acting as a media transcoder in this manner does 1960 not have its own SSRC, and hence is not visible to other entities at 1961 the RTP layer. RTCP ECN feedback packets and RTCP XR report blocks 1962 for ECN summary information that are received from downstream relate 1963 to the translated stream, and so must be processed by the translator 1964 as if it were the original media source. These reports drive the 1965 congestion control loop and media adaptation between the translator 1966 and the downstream receiver. If there are multiple downstream 1967 receivers, a logically separate transcoder instance must be used for 1968 each receiver, and must process RTCP ECN feedback and summary reports 1969 independently to the other transcoder instances. An RTP translator 1970 acting as a media transcoder in this manner MUST NOT forward RTCP ECN 1971 feedback packets or RTCP XR ECN summary reports from downstream 1972 receivers in the upstream direction. 1974 An RTP translator acting as a media transcoder will generate RTCP 1975 reports upstream towards the original media sender, based on the 1976 reception quality of the original media stream at the translator. 1977 The translator will run a separate congestion control loop and media 1978 adaptation between itself and the media sender for each of its 1979 downstream receivers, and must generate RTCP ECN feedback packets and 1980 RTCP XR ECN summary reports for that congestion control loop using 1981 the SSRC of that downstream receiver. 1983 8.4. Generating RTCP ECN Feedback in Mixers 1985 An RTP mixer terminates one-or-more RTP flows, combines them into a 1986 single outgoing media stream, and transmits that new stream as a 1987 separate RTP flow. A mixer has its own SSRC, and is visible to other 1988 participants in the session at the RTP layer. 1990 An ECN-aware RTP mixer must generate RTCP ECN feedback packets and 1991 RTCP XR report blocks for ECN summary information relating to the RTP 1992 flows it terminates, in exactly the same way it would if it were an 1993 RTP receiver. These reports form part of the congestion control loop 1994 between the mixer and the media senders generating the streams it is 1995 mixing. A separate control loop runs between each sender and the 1996 mixer. 1998 An ECN-aware RTP mixer will negotiate and initiate the use of ECN on 1999 the mixed RTP flows it generates, and will accept and process RTCP 2000 ECN feedback reports and RTCP XR report blocks for ECN relating to 2001 those mixed flows as if it were a standard media sender. A 2002 congestion control loop runs between the mixer and its receivers, 2003 driven in part by the ECN reports received. 2005 An RTP mixer MUST NOT forward RTCP ECN feedback packets or RTCP XR 2006 ECN summary reports from downstream receivers in the upstream 2007 direction. 2009 9. Implementation considerations 2011 To allow the use of ECN with RTP over UDP, the RTP implementation 2012 should be able to set the ECT bits in outgoing UDP datagrams, and 2013 should be able to read the value of the ECT bits on received UDP 2014 datagrams. The standard Berkeley sockets API pre-dates the 2015 specification of ECN, and does not provide the functionality which is 2016 required for this mechanism to be used with UDP flows, making this 2017 specification difficult to implement portably. 2019 10. IANA Considerations 2021 Note to RFC Editor: please replace "RFC XXXX" below with the RFC 2022 number of this memo, and remove this note. 2024 10.1. SDP Attribute Registration 2026 Following the guidelines in [RFC4566], the IANA is requested to 2027 register one new SDP attribute: 2029 o Contact name, email address and telephone number: Authors of 2030 RFCXXXX 2032 o Attribute-name: ecn-capable-rtp 2034 o Type of attribute: media-level 2036 o Subject to charset: no 2038 This attribute defines the ability to negotiate the use of ECT (ECN 2039 capable transport) for RTP flows running over UDP/IP. This attribute 2040 should be put in the SDP offer if the offering party wishes to 2041 receive an ECT flow. The answering party should include the 2042 attribute in the answer if it wish to receive an ECT flow. If the 2043 answerer does not include the attribute then ECT MUST be disabled in 2044 both directions. 2046 10.2. RTP/AVPF Transport Layer Feedback Message 2048 The IANA is requested to register one new RTP/AVPF Transport Layer 2049 Feedback Message in the table of FMT values for RTPFB Payload Types 2050 [RFC4585] as defined in Section 5.1: 2052 Name: RTCP-ECN-FB 2053 Long name: RTCP ECN Feedback 2054 Value: TBA1 2055 Reference: RFC XXXX 2057 10.3. RTCP Feedback SDP Parameter 2059 The IANA is requested to register one new SDP "rtcp-fb" attribute 2060 "nack" parameter "ecn" in the SDP ("ack" and "nack" Attribute Values) 2061 registry. 2063 Value name: ecn 2064 Long name: Explicit Congestion Notification 2065 Usable with: nack 2066 Reference: RFC XXXX 2068 10.4. RTCP XR Report blocks 2070 The IANA is requested to register one new RTCP XR Block Type as 2071 defined in Section 5.2: 2073 Block Type: TBA2 2074 Name: ECN Summary Report 2075 Reference: RFC XXXX 2077 10.5. RTCP XR SDP Parameter 2079 The IANA is requested to register one new RTCP XR SDP Parameter "ecn- 2080 sum" in the "RTCP XR SDP Parameters" registry. 2082 Parameter name XR block (block type and name) 2083 -------------- ------------------------------------ 2084 ecn-sum TBA2 ECN Summary Report Block 2086 10.6. STUN attribute 2088 A new STUN [RFC5389] attribute in the Comprehension-optional range 2089 under IETF Review (0x0000 - 0x3FFF) is request to be assigned to the 2090 STUN attribute defined in Section 7.2.2. The STUN attribute registry 2091 can currently be found at: http://www.iana.org/assignments/ 2092 stun-parameters/stun-parameters.xhtml. 2094 10.7. ICE Option 2096 A new ICE option "rtp+ecn" is registered in the registry that "IANA 2097 Registry for Interactive Connectivity Establishment (ICE) Options" 2098 [I-D.ietf-mmusic-ice-options-registry] creates. 2100 11. Security Considerations 2102 The usage of ECN with RTP over UDP as specified in this document has 2103 the following known security issues that need to be considered. 2105 External threats to the RTP and RTCP traffic: 2107 Denial of Service affecting RTCP: For an attacker that can modify 2108 the traffic between the media sender and a receiver can achieve 2109 either of two things: 1) Report a lot of packets as being 2110 Congestion Experience marked, thus forcing the sender into a 2111 congestion response; or 2) Ensure that the sender disable the 2112 usage of ECN by reporting failures to receive ECN by changing the 2113 counter fields. This can also be accomplished by injecting false 2114 RTCP packets to the media sender. Reporting a lot of CE marked 2115 traffic is likely the more efficient denial of service tool as 2116 that may likely force the application to use lowest possible bit- 2117 rates. The prevention against an external threat is to integrity 2118 protect the RTCP feedback information and authenticate the sender 2119 of it. 2121 Information leakage: The ECN feedback mechanism exposes the 2122 receivers perceived packet loss, what packets it considers to be 2123 ECN-CE marked and its calculation of the ECN-none. This is mostly 2124 not considered as sensitive information. If it is considered 2125 sensitive the RTCP feedback should be encrypted. 2127 Changing the ECN bits: An on-path attacker that sees the RTP packet 2128 flow from sender to receiver and who has the capability to change 2129 the packets can rewrite ECT into ECN-CE thus forcing the sender or 2130 receiver to take congestion control response. This denial of 2131 service against the media quality in the RTP session is impossible 2132 for an end-point to protect itself against. Only network 2133 infrastructure nodes can detect this illicit re-marking. It will 2134 be mitigated by turning off ECN, however, if the attacker can 2135 modify its response to drop packets the same vulnerability exist. 2137 Denial of Service affecting the session set-up signalling: If an 2138 attacker can modify the session signalling it can prevent the 2139 usage of ECN by removing the signalling attributes used to 2140 indicate that the initiator is capable and willing to use ECN with 2141 RTP/UDP. This attack can be prevented by authentication and 2142 integrity protection of the signalling. We do note that any 2143 attacker that can modify the signalling has more interesting 2144 attacks they can perform than prevent the usage of ECN, like 2145 inserting itself as a middleman in the media flows enabling wire- 2146 tapping also for an off-path attacker. 2148 The following are threats that exist from misbehaving senders or 2149 receivers: 2151 Receivers cheating: A receiver may attempt to cheat and fail to 2152 report reception of ECN-CE marked packets. The benefit for a 2153 receiver cheating in its reporting would be to get an unfair bit- 2154 rate share across the resource bottleneck. It is far from certain 2155 that a receiver would be able to get a significant larger share of 2156 the resources. That assumes a high enough level of aggregation 2157 that there are flows to acquire shares from. The risk of cheating 2158 is that failure to react to congestion results in packet loss and 2159 increased path delay. 2161 Receivers misbehaving: A receiver may prevent the usage of ECN in an 2162 RTP session by reporting itself as non ECN capable, forcing the 2163 sender to turn off usage of ECN. In a point-to-point scenario 2164 there is little incentive to do this as it will only affect the 2165 receiver. Thus failing to utilise an optimisation. For multi- 2166 party session there exist some motivation why a receiver would 2167 misbehave as it can prevent also the other receivers from using 2168 ECN. As an insider into the session it is difficult to determine 2169 if a receiver is misbehaving or simply incapable, making it 2170 basically impossible in the incremental deployment phase of ECN 2171 for RTP usage to determine this. If additional information about 2172 the receivers and the network is known it might be possible to 2173 deduce that a receiver is misbehaving. If it can be determined 2174 that a receiver is misbehaving, the only response is to exclude it 2175 from the RTP session and ensure that is does not any longer have 2176 any valid security context to affect the session. 2178 Misbehaving Senders: The enabling of ECN gives the media packets a 2179 higher degree of probability to reach the receiver compared to 2180 not-ECT marked ones on a ECN capable path. However, this is no 2181 magic bullet and failure to react to congestion will most likely 2182 only slightly delay a network buffer over-run, in which its 2183 session also will experience packet loss and increased delay. 2184 There is some possibility that the media senders traffic will push 2185 other traffic out of the way without being affected too 2186 negatively. However, we do note that a media sender still needs 2187 to implement congestion control functions to prevent the media 2188 from being badly affected by congestion events. Thus the 2189 misbehaving sender is getting a unfair share. This can only be 2190 detected and potentially prevented by network monitoring and 2191 administrative entities. See Section 7 of [RFC3168] for more 2192 discussion of this issue. 2194 We note that the end-point security functions needed to prevent an 2195 external attacker from inferring with the signalling are source 2196 authentication and integrity protection. To prevent information 2197 leakage from the feedback packets encryption of the RTCP is also 2198 needed. For RTP there exist multiple solutions possible depending on 2199 the application context. Secure RTP (SRTP) [RFC3711] does satisfy 2200 the requirement to protect this mechanism despite only providing 2201 authentication if a entity is within the security context or not. 2202 IPsec [RFC4301] and DTLS [RFC4347] can also provide the necessary 2203 security functions. 2205 The signalling protocols used to initiate an RTP session also need to 2206 be source authenticated and integrity protected to prevent an 2207 external attacker from modifying any signalling. Here an appropriate 2208 mechanism to protect the used signalling needs to be used. For SIP/ 2209 SDP ideally S/MIME [RFC5751] would be used. However, with the 2210 limited deployment a minimal mitigation strategy is to require use of 2211 SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least accomplish hop- 2212 by-hop protection. 2214 We do note that certain mitigation methods will require network 2215 functions. 2217 12. Examples of SDP Signalling 2219 This section contain a few different examples of the signalling 2220 mechanism defined in this specification in an SDP context. If there 2221 are discrepancies between these examples and the specification text, 2222 the specification text is definitive. 2224 12.1. Basic SDP Offer/Answer 2226 This example is a basic offer/answer SDP exchange, assumed done by 2227 SIP (not shown). The intention is to establish a basic audio session 2228 point to point between two users. 2230 The Offer: 2232 v=0 2233 o=jdoe 3502844782 3502844782 IN IP4 10.0.1.4 2234 s=VoIP call 2235 i=SDP offer for VoIP call with ICE and ECN for RTP 2236 b=AS:128 2237 b=RR:2000 2238 b=RS:2500 2239 a=ice-pwd:YH75Fviy6338Vbrhrlp8Yh 2240 a=ice-ufrag:9uB6 2241 a=ice-options:rtp+ecn 2242 t=0 0 2243 m=audio 45664 RTP/AVPF 97 98 99 2244 c=IN IP4 192.0.2.3 2245 a=rtpmap:97 G719/48000/1 2246 a=fmtp:97 maxred=160 2247 a=rtpmap:98 AMR-WB/16000/1 2248 a=fmtp:98 octet-align=1; mode-change-capability=2 2249 a=rtpmap:99 PCMA/8000/1 2250 a=maxptime:160 2251 a=ptime:20 2252 a=ecn-capable-rtp: ice rtp ect=0 mode=setread 2253 a=rtcp-fb:* nack ecn 2254 a=rtcp-fb:* trr-int 1000 2255 a=rtcp-xr:ecn-sum 2256 a=rtcp-rsize 2257 a=candidate:1 1 UDP 2130706431 10.0.1.4 8998 typ host 2258 a=candidate:2 1 UDP 1694498815 192.0.2.3 45664 typ srflx raddr 2259 10.0.1.4 rport 8998 2261 This SDP offer offers a single media stream with 3 media payload 2262 types. It proposes to use ECN with RTP, with the ICE based 2263 initialization as being preferred over the RTP/RTCP one. Leap of 2264 faith is not suggested to be used. The offerer is capable of both 2265 setting and reading the ECN bits. In addition the RTCP ECN feedback 2266 packet is configured and the RTCP XR ECN summary report. ICE is also 2267 proposed with two candidates. It also supports reduced size RTCP and 2268 are willing to use it. 2270 The Answer: 2272 v=0 2273 o=jdoe 3502844783 3502844783 IN IP4 198.51.100.235 2274 s=VoIP call 2275 i=SDP offer for VoIP call with ICE and ECN for RTP 2276 b=AS:128 2277 b=RR:2000 2278 b=RS:2500 2279 a=ice-pwd:asd88fgpdd777uzjYhagZg 2280 a=ice-ufrag:8hhY 2281 a=ice-options:rtp+ecn 2282 t=0 0 2283 m=audio 53879 RTP/AVPF 97 99 2284 c=IN IP4 198.51.100.235 2285 a=rtpmap:97 G719/48000/1 2286 a=fmtp:97 maxred=160 2287 a=rtpmap:99 PCMA/8000/1 2288 a=maxptime:160 2289 a=ptime:20 2290 a=ecn-capable-rtp: ice ect=0 mode=readonly 2291 a=rtcp-fb:* nack ecn 2292 a=rtcp-fb:* trr-int 1000 2293 a=rtcp-xr:ecn-sum 2294 a=candidate:1 1 UDP 2130706431 198.51.100.235 53879 typ host 2296 The answer confirms that only one media stream will be used. One RTP 2297 Payload type was removed. ECN capability was confirmed, and the 2298 initialization method will be ICE. However, the answerer is only 2299 capable of reading the ECN bits, which means that ECN can only be 2300 used for RTP flowing from the offerer to the answerer. ECT always 2301 set to 0 will be used in both directions. Both the RTCP ECN feedback 2302 packet and the RTCP XR ECN summary report will be used. Reduced size 2303 RTCP will not be used as the answerer has not indicated support for 2304 it in the answer. 2306 12.2. Declarative Multicast SDP 2308 The below session describes an any source multicast using session 2309 with a single media stream. 2311 v=0 2312 o=jdoe 3502844782 3502844782 IN IP4 198.51.100.235 2313 s=Multicast SDP session using ECN for RTP 2314 i=Multicasted audio chat using ECN for RTP 2315 b=AS:128 2316 t=3502892703 3502910700 2317 m=audio 56144 RTP/AVPF 97 2318 c=IN IP4 233.252.0.212/127 2319 a=rtpmap:97 g719/48000/1 2320 a=fmtp:97 maxred=160 2321 a=maxptime:160 2322 a=ptime:20 2323 a=ecn-capable-rtp: rtp mode=readonly; ect=0 2324 a=rtcp-fb:* nack ecn 2325 a=rtcp-fb:* trr-int 1500 2326 a=rtcp-xr:ecn-sum 2328 In the above example, as this is declarative we need to require 2329 certain functionality. As it is ASM the initialization method that 2330 can work here is the RTP/RTCP based one. So that is indicated. The 2331 ECN setting and reading capability to take part of this session is at 2332 least read. If one is capable of setting that is good, but not 2333 required as one can skip using ECN for anything one sends oneself. 2334 The ECT value is recommended to be set to 0 always. The ECN usage in 2335 this session requires both ECN feedback and the XR ECN summary 2336 report, so their use is also indicated. 2338 13. Open Issues 2340 As this draft is under development some known open issues exist and 2341 are collected here. Please consider them and provide input. 2343 1. The negotiation and directionality attribute is going to need 2344 some consideration for multi-party sessions when readonly 2345 capability might be sufficient to enable ECN for all incoming 2346 streams. However, it would beneficial to know if no potential 2347 sender support setting ECN. 2349 2. Consider initiation optimizations that allows for multi SSRC 2350 sender nodes to still have rapid usage of ECN. 2352 3. Should we report congestion in bytes or packets? RTCP usually 2353 does this in terms of packets, but there may be an argument that 2354 we want to report bytes for ECN. 2355 draft-ietf-tsvwg-byte-pkt-congest is extremely unclear on what is 2356 the right approach. 2358 4. We have a saturation problem with the packet loss counters. They 2359 do need to continue working even if saturation happens due to 2360 long sessions where more lost packets than the counters can 2361 handle. 2363 14. Acknowledgments 2365 The authors wish to thank the following persons for their reviews and 2366 comments: Thomas Belling, Bob Briscoe, Roni Even, Thomas Frankkila, 2367 Christian Groves, Cullen Jennings Tom Van Caenegem, Simo 2368 Veikkolainen, Lei Zhu, Christer Holmgren. 2370 15. References 2372 15.1. Normative References 2374 [I-D.ietf-mmusic-ice-options-registry] 2375 Westerlund, M. and C. Perkins, "IANA Registry for 2376 Interactive Connectivity Establishment (ICE) Options", 2377 draft-ietf-mmusic-ice-options-registry-02 (work in 2378 progress), May 2011. 2380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2381 Requirement Levels", BCP 14, RFC 2119, March 1997. 2383 [RFC2762] Rosenberg, J. and H. Schulzrinne, "Sampling of the Group 2384 Membership in RTP", RFC 2762, February 2000. 2386 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2387 of Explicit Congestion Notification (ECN) to IP", 2388 RFC 3168, September 2001. 2390 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2391 Jacobson, "RTP: A Transport Protocol for Real-Time 2392 Applications", STD 64, RFC 3550, July 2003. 2394 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 2395 Protocol Extended Reports (RTCP XR)", RFC 3611, 2396 November 2003. 2398 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2399 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2401 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2402 (ICE): A Protocol for Network Address Translator (NAT) 2403 Traversal for Offer/Answer Protocols", RFC 5245, 2404 April 2010. 2406 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 2407 Friendly Rate Control (TFRC): Protocol Specification", 2408 RFC 5348, September 2008. 2410 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2411 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 2412 October 2008. 2414 15.2. Informative References 2416 [I-D.ietf-avt-rtp-no-op] 2417 Andreasen, F., "A No-Op Payload Format for RTP", 2418 draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. 2420 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 2421 RFC 1112, August 1989. 2423 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2424 Announcement Protocol", RFC 2974, October 2000. 2426 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2427 A., Peterson, J., Sparks, R., Handley, M., and E. 2428 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2429 June 2002. 2431 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2432 with Session Description Protocol (SDP)", RFC 3264, 2433 June 2002. 2435 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 2436 Congestion Notification (ECN) Signaling with Nonces", 2437 RFC 3540, June 2003. 2439 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2440 Video Conferences with Minimal Control", STD 65, RFC 3551, 2441 July 2003. 2443 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 2444 Multicast (SSM)", RFC 3569, July 2003. 2446 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2447 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2448 RFC 3711, March 2004. 2450 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2451 Internet Protocol", RFC 4301, December 2005. 2453 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2454 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 2456 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2457 Security", RFC 4347, April 2006. 2459 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2460 Description Protocol", RFC 4566, July 2006. 2462 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2463 "Extended RTP Profile for Real-time Transport Control 2464 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2465 July 2006. 2467 [RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V., and R. 2468 Hakenberg, "RTP Retransmission Payload Format", RFC 4588, 2469 July 2006. 2471 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 2472 IP", RFC 4607, August 2006. 2474 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 2475 RFC 4960, September 2007. 2477 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 2478 Real-time Transport Control Protocol (RTCP)-Based Feedback 2479 (RTP/SAVPF)", RFC 5124, February 2008. 2481 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 2482 Real-Time Transport Control Protocol (RTCP): Opportunities 2483 and Consequences", RFC 5506, April 2009. 2485 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 2486 Initiation Protocol (SIP)", RFC 5630, October 2009. 2488 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2489 Mail Extensions (S/MIME) Version 3.2 Message 2490 Specification", RFC 5751, January 2010. 2492 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 2493 Protocol (RTCP) Extensions for Single-Source Multicast 2494 Sessions with Unicast Feedback", RFC 5760, February 2010. 2496 [RFC6189] Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 2497 Path Key Agreement for Unicast Secure RTP", RFC 6189, 2498 April 2011. 2500 Authors' Addresses 2502 Magnus Westerlund 2503 Ericsson 2504 Farogatan 6 2505 SE-164 80 Kista 2506 Sweden 2508 Phone: +46 10 714 82 87 2509 Email: magnus.westerlund@ericsson.com 2511 Ingemar Johansson 2512 Ericsson 2513 Laboratoriegrand 11 2514 SE-971 28 Lulea 2515 SWEDEN 2517 Phone: +46 73 0783289 2518 Email: ingemar.s.johansson@ericsson.com 2520 Colin Perkins 2521 University of Glasgow 2522 School of Computing Science 2523 Glasgow G12 8QQ 2524 United Kingdom 2526 Email: csp@csperkins.org 2528 Piers O'Hanlon 2529 University College London 2530 Computer Science Department 2531 Gower Street 2532 London WC1E 6BT 2533 United Kingdom 2535 Email: p.ohanlon@cs.ucl.ac.uk 2536 Ken Carlberg 2537 G11 2538 1600 Clarendon Blvd 2539 Arlington VA 2540 USA 2542 Email: carlberg@g11.org.uk