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