idnits 2.17.1 draft-ietf-avt-ecn-for-rtp-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (July 10, 2010) is 5040 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: 'TBA2' is mentioned on line 1527, but not defined == Missing Reference: 'TBA3' is mentioned on line 1588, but not defined ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-10) exists of draft-ietf-tsvwg-ecn-tunnel-08 -- Obsolete informational reference (is this intentional?): RFC 4347 (Obsoleted by RFC 6347) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 4960 (Obsoleted by RFC 9260) -- Obsolete informational reference (is this intentional?): RFC 5751 (Obsoleted by RFC 8551) Summary: 2 errors (**), 0 flaws (~~), 5 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: January 11, 2011 C. Perkins 6 University of Glasgow 7 P. O'Hanlon 8 UCL 9 K. Carlberg 10 G11 11 July 10, 2010 13 Explicit Congestion Notification (ECN) for RTP over UDP 14 draft-ietf-avt-ecn-for-rtp-02 16 Abstract 18 This document specifies how explicit congestion notification (ECN) 19 can be used with RTP/UDP flows that use RTCP as feedback mechanism. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 11, 2011. 38 Copyright Notice 40 Copyright (c) 2010 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Conventions, Definitions and Acronyms . . . . . . . . . . . . 4 57 3. Discussion, Requirements, and Design Rationale . . . . . . . . 4 58 3.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 59 3.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Use of ECN with RTP/UDP/IP . . . . . . . . . . . . . . . . . . 9 61 4.1. Negotiation of ECN Capability . . . . . . . . . . . . . . 12 62 4.2. Initiation of ECN Use in an RTP Session . . . . . . . . . 17 63 4.3. Ongoing Use of ECN Within an RTP Session . . . . . . . . . 22 64 4.4. Detecting Failures and Receiver Misbehaviour . . . . . . . 26 65 5. RTCP Extensions for ECN feedback . . . . . . . . . . . . . . . 29 66 5.1. ECN Feedback packet . . . . . . . . . . . . . . . . . . . 29 67 5.2. RTCP XR Report block for ECN summary information . . . . . 32 68 5.3. RTCP XR Report Block for ECN Nonce . . . . . . . . . . . . 33 69 6. Processing RTCP ECN Feedback in RTP Translators and Mixers . . 36 70 6.1. Fragmentation and Reassembly in Translators . . . . . . . 36 71 6.2. Generating RTCP ECN Feedback in Media Transcoders . . . . 38 72 6.3. Generating RTCP ECN Feedback in Mixers . . . . . . . . . . 39 73 7. Implementation considerations . . . . . . . . . . . . . . . . 40 74 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 75 8.1. SDP Attribute Registration . . . . . . . . . . . . . . . . 40 76 8.2. AVPF Transport Feedback Message . . . . . . . . . . . . . 40 77 8.3. RTCP XR Report blocks . . . . . . . . . . . . . . . . . . 40 78 8.4. STUN attribute . . . . . . . . . . . . . . . . . . . . . . 41 79 8.5. ICE Option . . . . . . . . . . . . . . . . . . . . . . . . 41 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 81 10. Examples of SDP Signalling . . . . . . . . . . . . . . . . . . 43 82 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 44 83 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 84 12.1. Normative References . . . . . . . . . . . . . . . . . . . 44 85 12.2. Informative References . . . . . . . . . . . . . . . . . . 45 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 46 88 1. Introduction 90 This document outlines how Explicit Congestion Notification (ECN) 91 [RFC3168] can be used for RTP [RFC3550] flows running over UDP/IP 92 which use RTCP as a feedback mechanism. The solution consists of 93 feedback of ECN congestion experienced markings to the sender using 94 RTCP, verification of ECN functionality end-to-end, and how to 95 initiate ECN usage. The initiation process will have some 96 dependencies on the signalling mechanism used to establish the RTP 97 session, a specification for signalling mechanisms using SDP is 98 included. 100 ECN is getting attention as a method to minimise the impact of 101 congestion on real-time multimedia traffic. When ECN is used, the 102 network can signal to applications that congestion is occurring, 103 whether that congestion is due to queuing at a congested link, 104 limited resources and coverage on a radio link, or other reasons. 105 This congestion signal allows applications to react in a controlled 106 manner, rather than responding to uncontrolled packet loss, and so 107 improves the user experience while benefiting the network. By 108 default, this reaction can be expected to be in the form of reducing 109 the transmission rate. In addition, the use of ECN support outlined 110 in this document helps minimize the disruption of the flow (and the 111 user experience) by rapidly conveying congested conditions without 112 packet loss. 114 The introduction of ECN into the Internet requires changes to both 115 the network and transport layers. At the network layer, IP 116 forwarding has to be updated to allow routers to mark packets, rather 117 than discarding them in times of congestion [RFC3168]. In addition, 118 transport protocols have to be modified to inform the sender that ECN 119 marked packets are being received, so it can respond to the 120 congestion. TCP [RFC3168], SCTP [RFC4960] and DCCP [RFC4340] have 121 been updated to support ECN, but to date there is no specification 122 how UDP-based transports, such as RTP [RFC3550], can use ECN. This 123 is due to the lack of feedback mechanisms directly in UDP. Instead 124 the signaling control protocol on top of UDP needs to provide that 125 feedback, which for RTP is RTCP. 127 The remainder of this memo is structured as follows. We start by 128 describing the conventions, definitions and acronyms used in this 129 memo in Section 2, and the design rationale and applicability in 130 Section 3. The means by which ECN is used with RTP over UDP is 131 defined in Section 4, along with RTCP extensions for ECN feedback in 132 Section 5. In Section 6 we discuss how RTCP ECN feedback is handled 133 in RTP translators and mixers. Section 7 discusses some 134 implementation considerations, Section 8 lists IANA considerations, 135 and Section 9 discusses the security considerations. 137 2. Conventions, Definitions and Acronyms 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 Abbreviations 145 ECN: Explicit Congestion Notification 147 ECT: ECN Capable Transport 149 ECN-CE: ECN Congestion Experienced 151 not-ECT: Not ECN Capable Transport 153 3. Discussion, Requirements, and Design Rationale 155 ECN has been specified for use with TCP [RFC3168], SCTP [RFC4960], 156 and DCCP [RFC4340] transports. These are all unicast protocols which 157 negotiate the use of ECN during the initial connection establishment 158 handshake (supporting incremental deployment, and checking if ECN 159 marked packets pass all middleboxes on the path). ECN Congestion 160 Experienced (ECN-CE) marks are immediately echoed back to the sender 161 by the receiving end-point using an additional bit in feedback 162 messages, and the sender then interprets the mark as equivalent to a 163 packet loss for congestion control purposes. 165 If RTP is run over TCP, SCTP, or DCCP, it can use the native ECN 166 support provided by those protocols. This memo does not concern 167 itself further with these use cases. However, RTP is more commonly 168 run over UDP. This combination does not currently support ECN, and 169 we observe that it has significant differences from the other 170 transport protocols for which ECN has been specified. These include: 172 Signalling: RTP relies on separate signalling protocols to negotiate 173 parameters before a session can be created, and doesn't include an 174 in-band handshake or negotiation at session set-up time (i.e. 175 there is no equivalent to the TCP three-way handshake in RTP). 177 Feedback: RTP does not explicitly acknowledge receipt of datagrams. 178 Instead, the RTP Control Protocol (RTCP) provides reception 179 quality feedback, and other back channel communication, for RTP 180 sessions. The feedback interval is generally on the order of 181 seconds, rather than once per network RTT (although the RTP/AVPF 182 profile [RFC4585] allows more rapid feedback in some cases). 184 Congestion Response: While it is possible to adapt the transmission 185 of many audio/visual streams in response to network congestion, 186 and such adaptation is required by [RFC3550], the dynamics of the 187 congestion response may be quite different to those of TCP or 188 other transport protocols. 190 Middleboxes: The RTP framework explicitly supports the concept of 191 mixers and translators, which are middleboxes that are involved in 192 media transport functions. 194 Multicast: RTP is explicitly a group communication protocol, and was 195 designed from the start to support IP multicast (primarily ASM, 196 although a recent extension supports SSM with unicast feedback). 198 Application Awareness: ECN support via TCP, DCCP, and SCTP constrain 199 the awareness and reaction to packet loss within those protocols. 200 By adding support of ECN through RTCP, the application is made 201 aware of packet loss and may choose one or more approaches in 202 response to that loss. 204 These differences will significantly alter the shape of ECN support 205 in RTP-over-UDP compared to ECN support in TCP, SCTP, and DCCP, but 206 do not invalidate the need for ECN support. Indeed, in many ways, 207 ECN support is more important for RTP sessions, since the impact of 208 packet loss in real-time audio-visual media flows is highly visible 209 to users. Effective ECN support for RTP flows running over UDP will 210 allow real-time audio-visual applications to respond to the onset of 211 congestion before routers are forced to drop packets, allowing those 212 applications to control how they reduce their transmission rate, and 213 hence media quality, rather than responding to, and trying to conceal 214 the effects of, unpredictable packet loss. Furthermore, widespread 215 deployment for ECN and active queue management in routers, should it 216 occur, can potentially reduce unnecessary queueing delays in routers, 217 lowering the round-trip time and benefiting interactive applications 218 of RTP, such as voice telephony. 220 3.1. Requirements 222 Considering ECN and these protocols one can create a set of 223 requirements that must be satisfied to at least some degree if ECN is 224 used by an other protocol (such as RTP over UDP) 226 o REQ 1: A mechanism MUST negotiate and initiate the usage of ECN 227 for RTP/UDP/IP sessions 229 o REQ 2: A mechanism MUST feedback the reception of any packets that 230 are ECN-CE marked to the packet sender 232 o REQ 3: Provide mechanism SHOULD minimise the possibility for 233 cheating 235 o REQ 4: Some detection and fallback mechanism SHOULD exist to avoid 236 loss of communication due to the attempted usage of ECN in case an 237 intermediate node clears ECT or drops packets that are ECT marked. 239 o REQ 5: Negotiation of ECN SHOULD NOT significantly increase the 240 time taken to negotiate and set-up the RTP session (an extra RTT 241 before the media can flow is unlikely to be acceptable for some 242 use cases). 244 o REQ 6: Negotiation of ECN SHOULD NOT cause media clipping at the 245 start of a session. 247 The following sections describes how these requirements can be meet 248 for RTP over UDP. 250 3.2. Applicability 252 The use of ECN with RTP over UDP is dependent on negotiation of ECN 253 capability between the sender and receiver(s), and validation of ECN 254 support in all elements of the network path(s) traversed. RTP is 255 used in a heterogeneous range of network environments and topologies, 256 with various different signalling protocols, all of which need to be 257 verified to support ECN before it can be used. 259 The usage of ECN is further dependent on a capability of the RTP 260 media flow to react to congestion signalled by ECN marked packets. 261 Depending on the application, media codec, and network topology, this 262 adaptation can occur various forms and at various nodes. As an 263 example, the sender can change the media encoding, or the receiver 264 can change the subscription to a layered encoding, or either reaction 265 can be accomplished by a transcoding middlebox. RFC 5117 identifies 266 seven topologies in which RTP sessions may be configured, and which 267 may affect the ability to use ECN: 269 Topo-Point-to-Point: This is a standard unicast flow. ECN may be 270 used with RTP in this topology in an analogous manner to its use 271 with other unicast transport protocols, with RTCP conveying ECN 272 feedback messages. 274 Topo-Multicast: This is either an any source multicast (ASM) group 275 with potentially several active senders and multicast RTCP 276 feedback, or a source specific multicast (SSM) group with a single 277 sender and unicast RTCP feedback from receivers. RTCP is designed 278 to scale to large group sizes while avoiding feedback implosion 279 (see Section 6.2 of [RFC3550], [RFC4585], and [RFC5760]), and can 280 be used by a sender to determine if all its receivers, and the 281 network paths to those receivers, support ECN (see Section 4.2). 282 It is somewhat more difficult to determine if all network paths 283 from all senders to all receivers support ECN. Accordingly, we 284 allow ECN to be used by an RTP sender using multicast UDP provided 285 the sender has verified that the paths to all its known receivers 286 support ECN, and irrespective of whether the paths from other 287 senders to their receivers support ECN. Note that group 288 membership may change during the lifetime of a multicast RTP 289 session, potentially introducing new receivers that are not ECN 290 capable. Senders must use the mechanisms described in Section 4.4 291 to monitor that all receivers continue to support ECN, and they 292 need to fallback to non-ECN use if any senders do not. 294 Topo-Translator: An RTP translator is an RTP-level middlebox that is 295 invisible to the other participants in the RTP session (although 296 it is usually visible in the associated signalling session). 297 There are two types of RTP translator: those do not modify the 298 media stream, and are concerned with transport parameters, for 299 example a multicast to unicast gateway; and those that do modify 300 the media stream, for example transcoding between different media 301 codecs. A single RTP session traverses the translator, and the 302 translator must rewrite RTCP messages passing through it to match 303 the changes it makes to the RTP data packets. A legacy, ECN- 304 unaware, RTP translator is expected to ignore the ECN bits on 305 received packets, and to set the ECN bits to not-ECT when sending 306 packets, so causing ECN negotiation on the path containing the 307 translator to fail (any new RTP translator that does not wish to 308 support ECN may do so similarly). An ECN aware RTP translator may 309 act in one of three ways: 311 * If the translator does not modify the media stream, it should 312 copy the ECN bits unchanged from the incoming to the outgoing 313 datagrams, unless it is overloaded and experiencing congestion, 314 in which case it may mark the outgoing datagrams with an ECN-CE 315 mark. Such a translator passes RTCP feedback unchanged. 317 * If the translator modifies the media stream to combine or split 318 RTP packets, but does not otherwise transcode the media, it 319 must manage the ECN bits in a way analogous to that described 320 in Section 5.3 of [RFC3168]: if an ECN marked packet is split 321 into two, then both the outgoing packets must be ECN marked 322 identically to the original; if several ECN marked packets are 323 combined into one, the outgoing packet must be either ECN-CE 324 marked or dropped if any of the incoming packets are ECN-CE 325 marked, and should be ECT marked if any of the incoming packets 326 are ECT marked. When RTCP ECN feedback packets (Section 5) are 327 received, they must be rewritten to match the modifications 328 made to the media stream (see Section 6.1). 330 * If the translator is a media transcoder, the output RTP media 331 stream may have radically different characteristics than the 332 input RTP media stream. Each side of the translator must then 333 be considered as a separate transport connection, with its own 334 ECN processing. This requires the translator interpose itself 335 into the ECN negotiation process, effectively splitting the 336 connection into two parts with their own negotiation. Once 337 negotiation has been completed, the translator must generate 338 RTCP ECN feedback back to the source based on its own 339 reception, and must respond to RTCP ECN feedback received from 340 the receiver(s) (see Section 6.2). 342 It is recognised that ECN and RTCP processing in an RTP translator 343 that modifies the media stream is non-trivial. 345 Topo-Mixer: A mixer is an RTP-level middlebox that aggregates 346 multiple RTP streams, mixing them together to generate a new RTP 347 stream. The mixer is visible to the other participants in the RTP 348 session, and is also usually visible in the associated signalling 349 session. The RTP flows on each side of the mixer are treated 350 independently for ECN purposes, with the mixer generating its own 351 RTCP ECN feedback, and responding to ECN feedback for data it 352 sends. Since connections are treated independently, it would seem 353 reasonable to allow the transport on one side of the mixer to use 354 ECN, while the transport on the other side of the mixer is not ECN 355 capable, if this is desired. 357 Topo-Video-switch-MCU: A video switching MCU receives several RTP 358 flows, but forwards only one of those flows onwards to the other 359 participants at a time. The flow that is forwarded changes during 360 the session, often based on voice activity. Since only a subset 361 of the RTP packets generated by a sender are forwarded to the 362 receivers, a video switching MCU can break ECN negotiation (the 363 success of the ECN negotiation may depend on the voice activity of 364 the participant at the instant the negotiation takes place - shout 365 if you want ECN). It also breaks congestion feedback and 366 response, since RTP packets are dropped by the MCU depending on 367 voice activity rather than network congestion. This topology is 368 widely used in legacy products, but is NOT RECOMMENDED for new 369 implementations and cannot be used with ECN. 371 Topo-RTCP-terminating-MCU: In this scenario, each participant runs 372 an RTP point-to-point session between itself and the MCU. Each of 373 these sessions is treated independently for the purposes of ECN 374 and RTCP feedback, potentially with some using ECN and some not. 376 Topo-Asymmetric: It is theoretically possible to build a middlebox 377 that is a combination of an RTP mixer in one direction and an RTP 378 translator in the other. To quote RFC 5117 "This topology is so 379 problematic and it is so easy to get the RTCP processing wrong, 380 that it is NOT RECOMMENDED to implement this topology." 382 These topologies may be combined within a single RTP session. 384 The ECN mechanism defined in this memo is applicable to both sender 385 and receiver controlled congestion algorithms. The mechanism ensures 386 that both senders and receivers will know about ECN-CE markings and 387 any packet losses. Thus the actual decision point for the congestion 388 control is not relevant. This is a great benefit as the rate of an 389 RTP session can be varied in a number of ways, for example a unicast 390 media sender might use TFRC [RFC5348] or some other algorithm, while 391 a multicast session could use a sender based scheme adapting to the 392 lowest common supported rate, or a receiver driven mechanism using 393 layered coding to support more heterogeneous paths. 395 To ensure timely feedback of CE marked packets, this mechanism 396 requires support for the RTP/AVPF profile [RFC4585] or any of its 397 derivatives, such as RTP/SAVPF [RFC5124]. The standard RTP/AVP 398 profile [RFC3551] does not allow any early or immediate transmission 399 of RTCP feedback, and has a minimal RTCP interval whose default value 400 (5 seconds) is many times the normal RTT between sender and receiver. 402 The control of which RTP data packets are marked as ECT, and whether 403 ECT(0) or ECT(1) is used, is due to the sender. RTCP packets MUST 404 NOT be ECT marked, whether generated by sender or receivers. 406 4. Use of ECN with RTP/UDP/IP 408 The solution for using ECN with RTP over UDP/IP consists of four 409 different pieces that together make the solution work: 411 1. Negotiation of the capability to use ECN with RTP/UDP/IP 413 2. Initiation and initial verification of ECN capable transport 415 3. Ongoing use of ECN within an RTP session 417 4. Failure detection, verification and fallback 419 Before an RTP session can be created, a signalling protocol is used 420 to discover the other participants and negotiate session parameters 421 (see Section 4.1). One of the parameters that can be negotiated is 422 the capability of a participant to support ECN functionality, or 423 otherwise. Note that all participants having the capability of 424 supporting ECN does not necessarily imply that ECN is usable in an 425 RTP session, since there may be middleboxes on the path between the 426 participants which don't pass ECN-marked packets (for example, a 427 firewall that blocks traffic with the ECN bits set). This document 428 defines the information that needs to be negotiated, and provides a 429 mapping to SDP for use in both declarative and offer/answer contexts. 431 When a sender joins a session for which all participants claim ECN 432 capability, it must verify if that capability is usable. There are 433 three ways in which this verification may be done (Section 4.2): 435 o The sender may generate a (small) subset of its RTP data packets 436 with the ECN field set to ECT(0) or ECT(1). Each receiver will 437 then send an RTCP feedback packet indicating the reception of the 438 ECT marked RTP packets. Upon reception of this feedback from each 439 receiver it knows of, the sender can consider ECN functional for 440 its traffic. Each sender does this verification independently of 441 each other. If a new receiver joins an existing session it also 442 needs to verify ECN support. If verification fails the sender 443 needs to stop using ECN. As the sender will not know of the 444 receiver prior to it sending RTP or RTCP packets, the sender will 445 wait for the first RTCP packet from the new receiver to determine 446 if that contains ECN feedback or not. 448 o Alternatively, ECN support can be verified during an initial end- 449 to-end STUN exchange (for example, as part of ICE connection 450 establishment). After having verified connectivity without ECN 451 capability an extra STUN exchange, this time with the ECN field 452 set to ECT(0) or ECT(1), is performed. If successful the path's 453 capability to convey ECN marked packets is verified. A new STUN 454 attribute is defined to convey feedback that the ECT marked STUN 455 request was received (see Section 8.4), along with an ICE 456 signalling option (Section 8.5). 458 o Thirdly, the sender may make a leap of faith that ECN will work. 459 This is only recommended for applications that know they are 460 running in controlled environments where ECN functionality has 461 been verified through other means. In this mode it is assumed 462 that ECN works, and the system reacts to failure indicators if the 463 assumption proved wrong. The use of this method relies on a high 464 confidence that ECN operation will be successful, or an 465 application where failure is not serious. The impact on the 466 network and other users must be considered when making a leap of 467 faith, so there are limitations on when this method is allowed. 469 The first mechanism, using RTP with RTCP feedback, has the advantage 470 of working for all RTP sessions, but the disadvantages of potential 471 clipping if ECN marked RTP packets are discarded by middleboxes, and 472 slow verification of ECN support. The STUN-based mechanism is faster 473 to verify ECN support, but only works in those scenarios supported by 474 end-to-end STUN, such as within an ICE exchange. The third one, 475 leap-of-faith, has the advantage of avoiding additional tests or 476 complexities and enabling ECN usage from the first media packet. The 477 downside is that if the end-to-end path contains middleboxes that do 478 not pass ECN, the impact on the application can be severe: in the 479 worst case, all media could be lost if a middlebox that discards ECN 480 marked packets is present. A less severe effect, but still requiring 481 reaction, is the presence of a middlebox that re-marks ECT marked 482 packets to non-ECT, possibly marking packets with a CE mark as non- 483 ECT. This can force the network into heavy congestion due to non- 484 responsiveness, and seriously impact media quality. 486 Once ECN support has been verified (or assumed) to work for all 487 receivers, a sender marks all its RTP packets as ECT packets, while 488 receivers rapidly feedback any CE marks to the sender using RTCP in 489 RTP/AVPF immediate or early feedback mode. An RTCP feedback report 490 is sent as soon as possible by the transmission rules for feedback 491 that are in place. This feedback report indicates the receipt of new 492 CE marks since the last ECN feedback packet, and also counts the 493 total number of CE marked packets through a cumulative sum. This is 494 the mechanism to provide the fastest possible feedback to senders 495 about CE marks. On receipt of a CE marked packet, the system must 496 react to congestion as-if packet loss has been reported. Section 4.3 497 describes the ongoing use of ECN with an RTP session. 499 This rapid feedback is not optimised for reliability, therefore an 500 additional procedure, the RTCP ECN summary reports, is used to ensure 501 more reliable, but less timely, reporting of the ECN information. 502 The ECN summary report contains the same information as the ECN 503 feedback format, only packed differently for better efficiency with 504 large reports. It is sent in a compound RTCP packet, along with 505 regular RTCP reception reports. By using cumulative counters for 506 seen CE, ECT, not-ECT and packet loss the sender can determine what 507 events have happened since the last report, independently of any RTCP 508 packets having been lost. 510 RTCP traffic MUST NOT be ECT marked for the following reason. ECT 511 marked traffic may be dropped if the path is not ECN compliant. As 512 RTCP is used to provide feedback about what has been transmitted and 513 what ECN markings that are received, it is important that these are 514 received in cases when ECT marked traffic is not getting through. 516 There are numerous reasons why the path the RTP packets take from the 517 sender to the receiver may change, e.g., mobility, link failure 518 followed by re-routing around it. Such an event may result in the 519 packet being sent through a node that is ECN non-compliant, thus re- 520 marking or dropping packets with ECT set. To prevent this from 521 impacting the application for longer than necessary, the operation of 522 ECN is constantly monitored by all senders. Both the RTCP ECN 523 summary reports and the ECN feedback packets allow the sender to 524 compare the number of ECT(0), ECT(1), and non-ECT marked packets 525 received with the number that were sent, while also reporting CE 526 marked and lost packets. If these numbers do not agree, it can be 527 inferred that the path does not reliably pass ECN-marked packets 528 (Section 4.4.2 discusses how to interpret the different cases). A 529 sender detecting a possible ECN non-compliance issue should then stop 530 sending ECT marked packets to determine if that allows the packets to 531 be correctly delivered. If the issues can be connected to ECN, then 532 ECN usage is suspended and possibly also re-negotiated. 534 This specification offers an option of computing and reporting an ECN 535 nonce over all received packets that were not ECN-CE marked or 536 reported explicitly lost. This provides an additional means to 537 detect any packet re-marking that happens in the network, and can 538 also be used by a sender to detect receivers that lie about reception 539 of CE-marked packets (it is to be noted that the incentive for 540 receivers to lie in their ECN reports is low for RTP/UDP/IP sessions, 541 since increased congestion levels are likely to cause unpredictable 542 packet losses that decrease the media quality more than would 543 reducing the data rate). To enable the sender to verify the ECN 544 nonce, the sender must learn the sequence number of all packets that 545 was either CE marked or lost, otherwise it can't correctly exclude 546 these packet from the ECN nonce sum. This is done using a new RTCP 547 XR report type, the Nonce Report, that contains the nonce sums and 548 indicating the lost or ECN-CE marked packets using a run length 549 encoded bit-vector (see Section 5.3). Due to the size of ECN Nonce 550 Reports, and as most RTP-based applications have little incentive to 551 lie about ECN marks, the use of the ECN nonce is OPTIONAL. 553 In the detailed specification of the behaviour below, the different 554 functions in the general case will first be discussed. In case 555 special considerations are needed for middleboxes, multicast usage 556 etc, those will be specially discussed in related subsections. 558 4.1. Negotiation of ECN Capability 560 The first stage of ECN negotiation for RTP-over-UDP is to signal the 561 capability to use ECN. This includes negotiating if ECN is to be 562 used symmetrically, the method for initial ECT verification, and 563 whether the ECN nonce is to be used. This memo defines the mappings 564 of this information onto SDP for both declarative and offer/answer 565 usage. There is one SDP extension to indicate if ECN support should 566 be used, and the method for initiation. In addition an ICE parameter 567 is defined to indicate that ECN initiation using STUN is supported as 568 part of an ICE exchange. 570 An RTP system that supports ECN and uses SDP in the signalling MUST 571 implement the SDP extension to signal ECN capability as described in 572 Section 4.1.1. It MAY also implement alternative ECN capability 573 negotiation schemes, such as the ICE extension described in 574 Section 4.1.2. 576 4.1.1. Signalling ECN Capability using SDP 578 One new SDP attribute, "a=ecn-capable-rtp", is defined. This is a 579 media level attribute, which MUST NOT be used at the session level. 580 It is not subject to the character set chosen. The aim of this 581 signalling is to indicate the capability of the sender and receivers 582 to support ECN, and to negotiate the method of ECN initiation to be 583 used in the session. The attribute takes a list of initiation 584 methods, ordered in decreasing preference. The defined values for 585 the initiation method are: 587 rtp: Using RTP and RTCP as defined in Section 4.2.1. 589 ice: Using STUN within ICE as defined in Section 4.2.2. 591 leap: Using the leap of faith method as defined in Section 4.2.3. 593 In addition, a number of OPTIONAL parameters may be included in the 594 "a=ecn-capable-rtp" attribute as follows: 596 o The "mode" parameter signals the endpoint's capability to set and 597 read ECN marks in UDP packets. An examination of various 598 operating systems has shown that end-system support for ECN 599 marking of UDP packets may be symmetric or asymmetric. By this we 600 mean that some systems may allow end points to set the ECN bits in 601 an outgoing UDP packet but not read them, while others may allow 602 applications to read the ECN bits but not set them. This 603 either/or case may produce an asymmetric support for ECN and thus 604 should be conveyed in the SDP signalling. The "mode=setread" 605 state is the ideal condition where an endpoint can both set and 606 read ECN bits in UDP packets. The "mode=setonly" state indicates 607 that an endpoint can set the ECT bit, but cannot read the ECN bits 608 from received UDP packets to determine if upstream congestion 609 occurred. The "mode=readonly" state indicates that the endpoint 610 can read the ECN bits to determine if downstream congestion has 611 occurred, but it cannot set the ECT bits in outgoing UDP packets. 612 When the "mode=" parameter is omitted it is assumed that the node 613 has "setread" capabilities. This option can provide for an early 614 indication that ECN cannot be used in a session. This would be 615 case when both the offerer and answerer set the "mode=" parameter 616 to "setonly" or "readonly", or when an RTP sender entity considers 617 offering "readonly". 619 o The "nonce" parameter may be used to signal whether the ECN nonce 620 is to be used in the session. This parameter takes two values; 621 "nonce=1" for nonce proposed or shall be used, and "nonce=0" for 622 no nonce. If this parameter is not specified, the default is no 623 nonce. 625 o The "ect" parameter makes it possible to express the preferred ECT 626 marking. This is either "random", "0", or "1", with "0" being 627 implied if not specified. The "ect" parameter describes a 628 receiver preference, and is useful in the case where the receiver 629 knows it is behind a link using IP header compression, the 630 efficiency of which would be seriously disrupted if it were to 631 receive packets with randomly chosen ECT marks. If the ECN nonce 632 is used then this parameter MUST be ignored, and random ECT is 633 implied; if the ECN nonce is not used, it is RECOMMENDED that 634 ECT(0) marking be used. 636 The ABNF [RFC5234] grammar for the "a=ecn-capable-rtp" attribute is 637 as follows: 639 ecn-attribute = "a=ecn-capable-rtp:" SP init-list SP parm-list 640 init-list = init-value *("," init-value) 641 init-value = "rtp" / "ice" / "leap" / init-ext 642 init-ext = token 643 parm-list = parm-value *(";" SP parm-value) 644 parm-value = nonce / mode / ect / parm-ext 645 mode = "mode=" ("setonly" / "setread" / "readonly") 646 nonce = "nonce=" ("0" / "1") 647 ect = "ect=" ("random" / "0" / "1") 648 parm-ext = parm-name "=" parm-value-ext 649 parm-name = token 650 parm-value-ext = token / quoted-string 651 quoted-string = DQUOTE *qdtext DQUOTE 652 qdtext = %x20-21 / %x23-7E / %x80-FF 653 ; any 8-bit ascii except <"> 655 ; external references: 656 ; token: from RFC 4566 657 ; SP and DQUOTE from RFC 5234 659 When SDP is used with the offer/answer model [RFC3264], the party 660 generating the SDP offer MUST insert an "a=ecn-capable-rtp" attribute 661 into the media section of the SDP offer of each RTP flow for which it 662 wishes to use ECN. The attribute includes one or more ECN initiation 663 methods in a comma separated list in decreasing order of preference, 664 with some number of optional parameters following. The answering 665 party compares the list of initiation methods in the offer with those 666 it supports in order of preference. If there is a match, and if the 667 receiver wishes to attempt to use ECN in the session, it includes an 668 "a=ecn-capable-rtp" attribute containing its single preferred choice 669 of initiation method in the media sections of the answer. If there 670 is no matching initiation method capability, or if the receiver does 671 not wish to attempt to use ECN in the session, it does not include an 672 "a=ecn-capable-rtp" attribute in its answer. If the attribute is 673 removed in the answer then ECN MUST NOT be used in any direction for 674 that media flow. The answer may also include optional parameters, as 675 discussed below. 677 If the "mode=setonly" parameter is present in the "a=ecn-capable-rtp" 678 attribute of the offer and the answering party is also 679 "mode=setonly", then there is no common ECN capability, and the 680 answer MUST NOT include the "a=ecn-capable-rtp" attribute. 681 Otherwise, if the offer is "mode=setonly" then ECN may only be 682 initiated in the direction from the offering party to the answering 683 party. 685 If the "mode=readonly" parameter is present in the "a=ecn-capable- 686 rtp" attribute of the offer and the answering party is 687 "mode=readonly", then there is no common ECN capability, and the 688 answer MUST NOT include the "a=ecn-capable-rtp" attribute. 689 Otherwise, if the offer is "mode=readonly" then ECN may only be 690 initiated in the direction from the answering party to the offering 691 party. 693 If the "mode=setread" parameter is present in the "a=ecn-capable-rtp" 694 attribute of the offer and the answering party is "setonly", then ECN 695 may only be initiated in the direction from the answering party to 696 the offering party. If the offering party is "mode=setread" but the 697 answering party is "mode=readonly", then ECN may only be initiated in 698 the direction from the offering party to the answering party. If 699 both offer and answer are "mode=setread", then ECN may be initiated 700 in both directions. Note that "mode=setread" is implied by the 701 absence of a "mode=" parameter in the offer or the answer. 703 If the "nonce=1" parameter is present in the "a=ecn-capable-rtp" 704 attribute of the offer, the answer MUST explicitly include the 705 "nonce=" parameter in the "a=ecn-capable-rtp" attribute of the answer 706 to indicate if it supports the ECN nonce. If the answer indicates 707 support ("nonce=1") then ECN nonce SHALL be used in the session; if 708 the answer does not include the "nonce=" parameter, or includes 709 "nonce=0", then the ECN nonce SHALL NOT be used. The answer MAY 710 include a "nonce=0" parameter in an answer even if not included in 711 the offer. This indicates that the answerer supports and is 712 interested in using ECN-nonce in this session, but it is not 713 currently enabled. If the offerer supports use of the nonce then it 714 SHOULD run a second round of offer/answer to enable use of the ECN 715 nonce. 717 The "ect=" parameter in the "a=ecn-capable-rtp" attribute is set 718 independently in the offer and the answer. Its value in the offer 719 indicates a preference for the behaviour of the answering party, and 720 its value in the answer indicates a preference for the behaviour of 721 the offering party. It will be the senders choice if to honor the 722 receivers preference or not. 724 When SDP is used in a declarative manner, for example in a multicast 725 session using the Session Announcement Protocol (SAP, [RFC2974]), 726 negotiation of session description parameters is not possible. The 727 "a=ecn-capable-rtp" attribute MAY be added to the session description 728 to indicate that the sender will use ECN in the RTP session. The 729 attribute MUST include a single method of initiation. Participants 730 MUST NOT join such a session unless they have the capability to 731 understand ECN-marked UDP packets, implement the method of 732 initiation, and can generate RTCP ECN feedback (note that having the 733 capability to use ECN doesn't necessarily imply that the underlying 734 network path between sender and receiver supports ECN). If the nonce 735 parameter is included then the ECN nonce SHALL be used in the 736 session. The mode parameter MAY be included also in declarative 737 usage, to indicate which capability is required by the consumer of 738 the SDP. So for example in a SSM session the participants configured 739 with a particular SDP will all be in a media receive only mode, thus 740 mode=readonly will work as the capability of reporting on the ECN 741 markings in the received is what is required. 743 The "a=ecn-capable-rtp" attribute MAY be used with RTP media sessions 744 using UDP/IP transport. It MUST NOT be used for RTP sessions using 745 TCP, SCTP, or DCCP transport, or for non-RTP sessions. 747 As described in Section 4.3.3, RTP sessions using ECN require rapid 748 RTCP ECN feedback, in order that the sender can react to ECN-CE 749 marked packets. Thus, the use of the Extended RTP Profile for RTCP- 750 Based Feedback (RTP/AVPF) [RFC4585] MUST be signalled. 752 When using ECN nonce, the RTCP XR signalling indicating the ECN Nonce 753 report MUST also be included in the SDP [RFC3611]. 755 4.1.2. ICE Parameter to Signal ECN Capability 757 One new ICE [RFC5245] option, "rtp+ecn", is defined. This is used 758 with the SDP session level "a=ice-options" attribute in an SDP offer 759 to indicate that the initiator of the ICE exchange has the capability 760 to support ECN for RTP-over-UDP flows (via "a=ice-options: rtp+ecn"). 761 The answering party includes this same attribute at the session level 762 in the SDP answer if it also has the capability, and removes the 763 attribute if it does not wish to use ECN, or doesn't have the 764 capability to use ECN. If this initiation method (Section 4.2.2) 765 actually is going to be used, it is explicitly negotiated using the 766 "a=ecn-capable-rtp" attribute. 768 Note: This signalling mechanism is not strictly needed as long as 769 the STUN ECN testing capability is used within the context of this 770 document. It may however be useful if the ECN verification 771 capability is used in additional contexts. 773 4.2. Initiation of ECN Use in an RTP Session 775 Once the sender and the receiver(s) have agreed that they have the 776 capability to use ECN within a session, they may attempt to initiate 777 ECN use. 779 At the start of the RTP session, when the first packets with ECT are 780 sent, it is important to verify that IP packets with ECN field values 781 of ECT or ECN-CE will reach their destination(s). There is some risk 782 that the use of ECN will result in either reset of the ECN field, or 783 loss of all packets with ECT or ECN-CE markings. If the path between 784 the sender and the receivers exhibits either of these behaviours one 785 needs to stop using ECN immediately to protect both the network and 786 the application. 788 The RTP senders and receivers SHALL NOT ECT mark their RTCP traffic 789 at any time. This is to ensure that packet loss due to ECN marking 790 will not effect the RTCP traffic and the necessary feedback 791 information it carries. 793 An RTP system that supports ECN MUST implement the initiation of ECN 794 using in-band RTP and RTCP described in Section 4.2.1. It MAY also 795 implement other mechanisms to initiate ECN support, for example the 796 STUN-based mechanism described in Section 4.2.2 or use the leap of 797 faith option if the session supports the limitations provided in 798 Section 4.2.3. If support for both in-band and out-of-band 799 mechanisms is signalled, the sender should try ECN negotiation using 800 STUN with ICE first, and if it fails, fallback to negotiation using 801 RTP and RTCP ECN feedback. 803 No matter how ECN usage is initiated, the sender MUST continually 804 monitor the ability of the network, and all its receivers, to support 805 ECN, following the mechanisms described in Section 4.4. This is 806 necessary because path changes or changes in the receiver population 807 may invalidate the ability of the network to support ECN. 809 4.2.1. Detection of ECT using RTP and RTCP 811 The ECN initiation phase using RTP and RTCP to detect if the network 812 path supports ECN comprises three stages. Firstly, the RTP sender 813 generates some small fraction of its traffic with ECT marks to act a 814 probe for ECN support. Then, on receipt of these ECT-marked packets, 815 the receivers send RTCP ECN feedback packets and RTCP ECN summary 816 reports to inform the sender that their path supports ECN. Finally, 817 the RTP sender makes the decision to use ECN or not, based on whether 818 the paths to all RTP receivers have been verified to support ECN. 820 Generating ECN Probe Packets: During the ECN initiation phase, an 821 RTP sender SHALL mark a small fraction of its RTP traffic as ECT, 822 while leaving the reminder of the packets unmarked. The main 823 reason for only marking some packets is to maintain usable media 824 delivery during the ECN initiation phase in those cases where ECN 825 is not supported by the network path. A secondary reason to send 826 some not-ECT packets are to ensure that the receivers will send 827 RTCP reports on this sender, even if all ECT marked packets are 828 lost in transit. The not-ECT packets also provide a base-line to 829 compare performance parameters against. An RTP sender is 830 RECOMMENDED to send a minimum of two packets with ECT markings per 831 RTCP reporting interval, one with ECT(0) and one with ECT(1), and 832 will continue to send some ECT marked traffic as long as the ECN 833 initiation phase continues. The sender SHOULD NOT mark all RTP 834 packets as ECT during the ECN initiation phase. 836 This memo does not mandate which RTP packets are marked with ECT 837 during the ECN initiation phase. An implementation should insert 838 ECT marks in RTP packets in a way that minimises the impact on 839 media quality if those packets are lost. The choice of packets to 840 mark is clearly very media dependent, but the usage of RTP NO-OP 841 payloads [I-D.ietf-avt-rtp-no-op], if supported, would be an 842 appropriate choice. For audio formats, if would make sense for 843 the sender to mark comfort noise packets or similar. For video 844 formats, packets containing P- or B-frames, rather than I-frames, 845 would be an appropriate choice. No matter which RTP packets are 846 marked, those packets MUST NOT be duplicated in transmission, 847 since their RTP sequence number is used to identify packets that 848 are received with ECN markings. 850 Generating RTCP ECN Feedback: If ECN capability has been negotiated 851 in an RTP session, the receivers in the session MUST listen for 852 ECT or ECN-CE marked RTP packets, and generate RTCP ECN feedback 853 packets (Section 5.1) to mark their receipt. An immediate or 854 early (depending on the RTP/AVPF mode) ECN feedback packet SHOULD 855 be generated on receipt of the first ECT or ECN-CE marked packet 856 from a sender that has not previously sent any ECT traffic. Each 857 regular RTCP report MUST also contain an ECN summary report 858 (Section 5.2). Reception of subsequent ECN-CE marked packets 859 SHOULD result in additional early or immediate ECN feedback 860 packets being sent. 862 Determination of ECN Support: RTP is a group communication protocol, 863 where members can join and leave the group at any time. This 864 complicates the ECN initiation phase, since the sender must wait 865 until it believes the group membership has stabilised before it 866 can determine if the paths to all receivers support ECN (group 867 membership changes after the ECN initiation phase has completed 868 are discussed in Section 4.3). 870 An RTP sender shall consider the group membership to be stable 871 after it has been in the session and sending ECT-marked probe 872 packets for at least three RTCP reporting intervals (i.e., after 873 sending its third regularly scheduled RTCP packet), and when a 874 complete RTCP reporting interval has passed without changes to the 875 group membership. ECN initiation is considered successful when 876 the group membership is stable, and all known participants have 877 sent one or more RTCP ECN feedback packets indicating correct 878 receipt of the ECT-marked RTP packets generated by the sender. 880 As an optimisation, if an RTP sender is initiating ECN usage 881 towards a unicast address, then it MAY treat the ECN initiation as 882 provisionally successful if it receives a single RTCP ECN feedback 883 report indicating successful receipt of the ECT-marked packets, 884 with no negative indications, from a single RTP receiver. After 885 declaring provisional success, the sender MAY generate ECT-marked 886 packets as described in Section 4.3, provided it continues to 887 monitor the RTCP reports for a period of three RTCP reporting 888 intervals from the time the ECN initiation started, to check if 889 there is any other participants in the session. If other 890 participants are detected, the sender MUST fallback to only ECT- 891 marking a small fraction of its RTP packets, while it determines 892 if ECN can be supported following the full procedure described 893 above. 895 Note: One use case that requires further consideration is a 896 unicast connection with several SSRCs multiplexed onto the same 897 flow (e.g., an SVC video using SSRC multiplexing for the 898 layers). It is desirable to be able to rapidly negotiate ECN 899 support for such a session, but the optimisation above fails 900 since the multiple SSRCs make it appear that this is a group 901 communication scenario. It's not sufficient to check that all 902 SSRCs map to a common RTCP CNAME to check if they're actually 903 located on the same device, because there are implementations 904 that use the same CNAME for different parts of a distributed 905 implementation. 907 ECN initiation is considered to have failed at the instant when 908 any RTP session participant sends an RTCP packet that doesn't 909 contain an RTCP ECN feedback report or ECN summary report, but has 910 an RTCP RR with an extended RTP sequence number field that 911 indicates that it should have received multiple (>3) ECT marked 912 RTP packets. This can be due to failure to support the ECN 913 feedback format by the receiver or some middlebox, or the loss of 914 all ECT marked packets. Both indicate a lack of ECN support. 916 If the ECN negotiation succeeds, this indicates that the path can 917 pass some ECN-marked traffic, and that the receivers support ECN 918 feedback. This does not necessarily imply that the path can robustly 919 convey ECN feedback; Section 4.3 describes the ongoing monitoring 920 that must be performed to ensure the path continues to robustly 921 support ECN. 923 4.2.2. Detection of ECT using STUN with ICE 925 This section describes an OPTIONAL method that can be used to avoid 926 media impact and also ensure an ECN capable path prior to media 927 transmission. This method is considered in the context where the 928 session participants are using ICE [RFC5245] to find working 929 connectivity. We need to use ICE rather than STUN only, as the 930 verification needs to happen from the media sender to the address and 931 port on which the receiver is listening. 933 To minimise the impact of set-up delay, and to prioritise the fact 934 that one has a working connectivity rather than necessarily finding 935 the best ECN capable network path, this procedure is applied after 936 having performed a successful connectivity check for a candidate, 937 which is nominated for usage. At that point, and provided the chosen 938 candidate is not a relayed address, an additional connectivity check 939 is performed, sending the "ECT Check" attribute in a STUN packet that 940 is ECT marked. On reception of the packet, the STUN server will note 941 the received ECN field value, and send a STUN/UDP/IP packet in reply, 942 with the ECN field set to not-ECT, and including an ECN check 943 attribute. 945 The STUN ECN check attribute contains one field and a flag. The flag 946 indicates if the echo field contains a valid value or not. The field 947 is the ECN echo field, and when valid contains the two ECN bits from 948 the packet it echoes back. The ECN check attribute is a 949 comprehension optional attribute. 951 0 1 2 3 952 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 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 954 | Type | Length | 955 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 956 | Reserved |ECF|V| 957 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 959 Figure 1: ECN Check STUN Attribute 961 V: Valid (1 bit) ECN Echo value field is valid when set to 1, and 962 invalid when set 0. 964 ECF: ECN Echo value field (2 bits) contains the ECN field value of 965 the STUN packet it echoes back when field is valid. If invalid 966 the content is arbitrary. 968 Reserved: Reserved bits (29 bits) SHOULD be set to 0 on 969 transmission, and SHALL be ignored on reception. 971 This attribute MAY be included in any STUN request to request the ECN 972 field to be echoed back. In STUN requests the V bit SHALL be set to 973 0. A STUN server receiving a request with the ECN Check attribute 974 which understand it SHALL read the ECN field value of the IP/UDP 975 packet the request was received in. Upon forming the response the 976 server SHALL include the ECN Check attribute setting the V bit to 977 valid and include the read value of the ECN field into the ECF field. 979 4.2.3. Leap of Faith ECT initiation method 981 This method for initiating ECN usage is a leap of faith that assumes 982 that ECN will work on the used path(s). It is not generally 983 recommended as the impact on both the application and the network may 984 be substantial if the path is not ECN capable. Applications may 985 experience high packet loss rates, this is both from dropped ECT 986 marked packets, and as a result of driving the network into higher 987 degrees of congestion by not being responsive to ECN marks. The 988 network may experience higher degrees of congestion due to the 989 unresponsiveness of the sender due to lost ECN-CE marks from non- 990 compliant re-marking. 992 The method is to go directly to "ongoing use of ECN" as defined in 993 Section 4.3. Thus all RTP packets MAY be marked as ECT and the 994 failure detection MUST be used to detect any case when the assumption 995 that the path was ECT capable is wrong. 997 If the sender marks all packets as ECT while transmitting on a path 998 that contains a middlebox that drops all ECT-marked packets, then a 999 receiver downstream of that middlebox will not receive any RTP data 1000 packets from that sender, and hence will not consider it to be an 1001 active RTP SSRC. The sender can detect this, since SR/RR packets 1002 from such receivers will either not include a report for the sender's 1003 SSRC, or will include a report claiming that no packets have been 1004 received. The sender should be aware that a receiver may generate 1005 its first RTCP packet immediately on joining a unicast session, or 1006 very shortly after joining a RTP/AVPF session, before it has had 1007 chance to receive any data packets. A sender that receives RTCP 1008 SR/RR packet indicating lack of reception by a receiver may therefore 1009 have to wait for a second RTCP report from that receiver to be sure 1010 that the lack of reception is due to ECT-marking. 1012 This method is only recommended for controlled environments where the 1013 whole path(s) between sender and receiver(s) has been built and 1014 verified to be ECT. It is NOT RECOMMENDED that the leap-of-faith ECT 1015 initiation method is used on unmanaged public Internet paths. 1017 4.2.4. ECN Nonce during initiation 1019 If the ECN Nonce was enabled in the signalling, it SHALL be used 1020 during the initiation phase as described in Section 4.3.2.1. 1022 4.3. Ongoing Use of ECN Within an RTP Session 1024 Once ECN usage has been successfully initiated for an RTP sender, 1025 that sender begins sending all RTP data packets as ECT-marked, and 1026 its receivers continue sending ECN feedback information via RTCP 1027 packets. This section describes procedures for sending ECT-marked 1028 data, providing ECN feedback information via RTCP, responding to ECN 1029 feedback information, and detecting failures and misbehaving 1030 receivers. 1032 4.3.1. Transmission of ECT-marked RTP Packets 1034 After a sender has successfully initiated ECN usage, it SHOULD mark 1035 all the RTP data packets it sends as ECT. The sender SHOULD mark 1036 packets as ECT(0) unless the receiver expresses a preference for 1037 ECT(1) or random choice using the "ect" parameter in the "a=ecn- 1038 capable-rtp" attribute; or unless the ECN nonce is in use, in which 1039 case random ECT marks MUST be used. If the sender selects a random 1040 choice of ECT marking, the sender MUST record the statistics for the 1041 different ECN values sent. If ECN nonce is activated the sender must 1042 record the value and calculate the ECN-nonce sum for outgoing packets 1043 [RFC3540] to allow the use of the ECN-nonce to detect receiver 1044 misbehaviour (see Section 4.4). Guidelines on the random choice of 1045 ECT values are provided in Section 8 of [RFC3540]. 1047 The sender SHALL NOT include ECT marks on outgoing RTCP packets, and 1048 SHOULD NOT include ECT marks on any other outgoing control messages 1049 (e.g. STUN [RFC5389] packets, DTLS [RFC4347] handshake packets, or 1050 ZRTP [I-D.zimmermann-avt-zrtp] control packets) that are multiplexed 1051 on the same UDP port. 1053 4.3.2. Reporting ECN Feedback via RTCP 1055 An RTP receiver that receives a packet with an ECN-CE mark, or that 1056 detects a packet loss, MUST schedule the transmission of an RTCP ECN 1057 feedback packet as soon as possible (subject to the constraints of 1058 [RFC4585] and [RFC3550]) to report this back to the sender. The 1059 feedback RTCP packet sent SHALL consist of at least one ECN feedback 1060 packet (Section 5) reporting on the packets received since the last 1061 ECN feedback packet, and SHOULD contain an RTCP SR or RR packet. The 1062 RTP/AVPF profile in early or immediate feedback mode SHOULD be used 1063 where possible, to reduce the interval before feedback can be sent. 1064 To reduce the size of the feedback message, reduced size RTCP 1065 [RFC5506] MAY be used if supported by the end-points. Both RTP/AVPF 1066 and reduced size RTCP MUST be negotiated in the session set-up 1067 signalling before they can be used. ECN Nonce information SHOULD NOT 1068 be included in early or immediate reports, only when regular reports 1069 are sent. 1071 Every time a regular compound RTCP packet is to be transmitted, an 1072 ECN-capable RTP receiver MUST include an RTCP XR ECN summary report 1073 as described in Section 5.2 as part of the compound packet. If ECN- 1074 nonce is enabled the receiver MUST also include an RTCP XR Nonce 1075 report packet as described in Section 5.3. It is important to 1076 configure the RTCP bandwidth (e.g. using an SDP "b=" line) such that 1077 the bit-rate is sufficient for a usage that includes these regular 1078 summary and nonce reports, and feedback on ECN-CE events. 1080 The multicast feedback implosion problem, that occurs when many 1081 receivers simultaneously send feedback to a single sender, must also 1082 be considered. The RTP/AVPF transmission rules will limit the amount 1083 of feedback that can be sent, avoiding the implosion problem but also 1084 delaying feedback by varying degrees from nothing up to a full RTCP 1085 reporting interval. As a result, the full extent of a congestion 1086 situation may take some time to reach the sender, although some 1087 feedback should arrive in a reasonably timely manner, allowing the 1088 sender to react on a single or a few reports. 1090 A possible future optimisation might be to define some form of 1091 feedback suppression mechanism to reduce the RTCP reporting 1092 overhead for group communication using ECN. 1094 In case a receiver driven congestion control algorithm is to be used 1095 and has been agreed upon through signalling, the algorithm MAY 1096 specify that the immediate scheduling (and later transmission) of 1097 ECN-CE feedback of any received ECN-CE mark is not required and shall 1098 not be done (since it is not necessary for congestion control 1099 purposes in such cases). In that case ECN feedback is only sent 1100 using regular RTCP reports for verification purpose and in response 1101 to the initiation process ("rtp") of any new media senders as 1102 specified in Section 4.2.1. 1104 4.3.2.1. ECN Nonce Reporting 1106 When ECN Nonce reporting is used, it requires both the ECN nonce sum 1107 and the sequence numbers for packets where the ECN marking has been 1108 lost to be reported. This information is variable size as it depends 1109 on both the total number of packet sent per reporting interval and 1110 the CE and Packet loss pattern how many bits are required for 1111 reporting. 1113 The RTCP packets may be lost, and to avoid the possibility for 1114 cheating by "losing" the Nonce information for where one is cheating 1115 the nonce coverage needs to be basically complete. Thus the Nonce 1116 reporting SHOULD cover at least the 3 regular reporting intervals. 1117 The only exception allowed is if the reporting information becomes 1118 too heavy and makes the RTCP report packet become larger than the 1119 MTU. In that case a receiver MAY reduce the coverage for the ECN 1120 nonce to only the last or two last reporting intervals. A sender 1121 should consider the received size report for cases where the coverage 1122 is not at least three reporting intervals and determine if this may 1123 be done to cheat or not. Failure to have reported on all intervals 1124 MAY be punished by reducing the congestion safe rate. 1126 The ECN nonce information in the ECN feedback packet consists of both 1127 a start value for the nonce prior to the first packet in the 1128 reporting interval and the final 2-bit XOR sum over all the received 1129 ECN values, both not-ECT and ECT for the report interval. The report 1130 interval is explicitly signalled in the RTCP XR Nonce report packet. 1131 The initial value for the Nonce is 00b. 1133 4.3.3. Response to Congestion Notifications 1135 When RTP packets are received with ECN-CE marks, the sender and/or 1136 receivers MUST react with congestion control as-if those packets had 1137 been lost. Depending on the media format, type of session, and RTP 1138 topology used, there are several different types of congestion 1139 control that can be used. 1141 Sender-Driven Congestion Control: The sender may be responsible for 1142 adapting the transmitted bit-rate in response to RTCP ECN 1143 feedback. When the sender receives the ECN feedback data it feeds 1144 this information into its congestion control or bit-rate 1145 adaptation mechanism so that it can react on it as if it was 1146 packet losses that was reported. The congestion control algorithm 1147 to be used is not specified here, although TFRC [RFC5348] is one 1148 example that might be used. 1150 Receiver-Driven Congestion Control: If a receiver driven congestion 1151 control mechanism is used, the receiver can react to the ECN-CE 1152 marks without contacting the sender. This may allow faster 1153 response than sender-driven congestion control in some 1154 circumstances. Receiver-driven congestion control is usually 1155 implemented by providing the content in a layered way, with each 1156 layer providing improved media quality but also increased 1157 bandwidth usage. The receiver locally monitors the ECN-CE marks 1158 on received packet to check if it experiences congestion at the 1159 current number of layers. If congestion is experienced, the 1160 receiver drops one layer, so reducing the resource consumption on 1161 the path towards itself. For example, if a layered media encoding 1162 scheme such as H.264 SVC is used, the receiver may change its 1163 layer subscription, and so reduce the bit rate it receives. The 1164 receiver MUST still send RTCP ECN feedback to the sender, even if 1165 it can adapt without contact with the sender, so that the sender 1166 can determine if ECN is supported on the network path. The 1167 timeliness of RTCP feedback is less of a concern with receiver 1168 driven congestion control, and regular RTCP reporting of ECN 1169 feedback is sufficient (without using RTP/AVPF immediate or early 1170 feedback). 1172 Responding to congestion indication in the case of multicast traffic 1173 is a more complex problem than for unicast traffic. The fundamental 1174 problem is diverse paths, i.e. when different receivers don't see the 1175 same path, and thus have different bottlenecks, so the receivers may 1176 get ECN-CE marked packets due to congestion at different points in 1177 the network. This is problematic for sender driven congestion 1178 control, since when receivers are heterogeneous in regards to 1179 capacity the sender is limited to transmitting at the rate the 1180 slowest receiver can support. This often becomes a significant 1181 limitation as group size grows. Also, as group size increases the 1182 frequency of reports from each receiver decreases, which further 1183 reduces the responsiveness of the mechanism. Receiver-driven 1184 congestion control has the advantage that each receiver can choose 1185 the appropriate rate for its network path, rather than all having to 1186 settle for the lowest common rate. 1188 We note that ECN support is not a silver bullet to improving 1189 performance. The use of ECN gives the chance to respond to 1190 congestion before packets are dropped in the network, improving the 1191 user experience by allowing the RTP application to control how the 1192 quality is reduced. An application which ignores ECN congestion 1193 experienced feedback is not immune to congestion: the network will 1194 eventually begin to discard packets if traffic doesn't respond. It 1195 is in the best interest of an application to respond to ECN 1196 congestion feedback promptly, to avoid packet loss. 1198 4.4. Detecting Failures and Receiver Misbehaviour 1200 ECN-nonce is defined in RFC3540 as a means to ensure that a TCP 1201 clients does not mask ECN-CE marks, this assumes that the sending 1202 endpoint (server) acts on behalf of the network. 1204 The assumption about the senders acting on the behalf of the network 1205 may be reduced due to the nature of peer-to-peer use of RTP. Still a 1206 significant portion of RTP senders are infrastructure devices (for 1207 example, streaming media servers) that do have an interest in 1208 protecting both service quality and the network. In addition, as 1209 real-time media is commonly sensitive to increased delay and packet 1210 loss, it will be in both media sender and receivers interest to 1211 minimise the number and duration of any congestion events as they 1212 will affect media quality. 1214 RTP sessions can also suffer from path changes resulting in a non-ECN 1215 compliant node becoming part of the path. That node may perform 1216 either of two actions that has effect on the ECN and application 1217 functionality. The gravest is if the node drops packets with any ECN 1218 field values other than 00b. This can be detected by the receiver 1219 when it receives a RTCP SR packet indicating that a sender has sent a 1220 number of packets has not been received. The sender may also detect 1221 it based on the receivers RTCP RR packet where the extended sequence 1222 number is not advanced due to the failure to receive packets. If the 1223 packet loss is less than 100% then packet loss reporting in either 1224 the ECN feedback information or RTCP RR will indicate the situation. 1225 The other action is to re-mark a packet from ECT to not-ECT. That 1226 has less dire results, however, it should be detected so that ECN 1227 usage can be suspended to prevent misusing the network. 1229 The ECN feedback packet allows the sender to compare the number of 1230 ECT marked packets of different type with the number it actually 1231 sent. The number of ECT packets received plus the number of CE 1232 marked and lost packets should correspond to the number of sent ECT 1233 marked packets. If this number doesn't agree there are two likely 1234 reasons, a translator changing the stream or not carrying the ECN 1235 markings forward, or that some node re-marks the packets. In both 1236 cases the usage of ECN is broken on the path. By tracking all the 1237 different possible ECN field values a sender can quickly detect if 1238 some non-compliant behavior is happing on the path. 1240 Thus packet losses and non-matching ECN field value statistics are 1241 possible indication of issues with using ECN over the path. The next 1242 section defines both sender and receiver reactions to these cases. 1244 4.4.1. Fallback mechanisms 1246 Upon the detection of a potential failure both the sender and the 1247 receiver can react to mitigate the situation. 1249 A receiver that detects a packet loss burst MAY schedule an early 1250 feedback packet to report this to the sender that includes at least 1251 the RTCP RR and the ECN feedback message. Thus speeding up the 1252 detection at the sender of the losses and thus triggering sender side 1253 mitigation. 1255 A sender that detects high packet loss rates for ECT-marked packets 1256 SHOULD immediately switch to sending packets as not-ECT to determine 1257 if the losses potentially are due to the ECT markings. If the losses 1258 disappear when the ECT-marking is discontinued, the RTP sender should 1259 go back to initiation procedures to attempt to verify the apparent 1260 loss of ECN capability of the used path. If a re-initiation fails 1261 then the two possible actions exist: 1263 1. Periodically retry the ECN initiation to detect if a path change 1264 occurs to a path that is ECN capable. 1266 2. Renegotiating the session to disable ECN support. This is a 1267 choice that is suitable if the impact of ECT probing on the media 1268 quality are noticeable. If multiple initiations has been 1269 successful but the following full usage of ECN has resulted in 1270 the fallback procedures then disabling of the ECN support is 1271 RECOMMENDED. 1273 We foresee the possibility of flapping ECN capability due to several 1274 reasons: video switching MCU or similar middleboxes that selects to 1275 deliver media from the sender only intermittently; load balancing 1276 devices may in worst case result in that some packets take a 1277 different network path then the others; mobility solutions that 1278 switches underlying network path in a transparent way for the sender 1279 or receiver; and membership changes in a multicast group. 1281 4.4.2. Interpretation of ECN Summary information 1283 This section contains discussion on how you can use the ECN summary 1284 report information in detecting various types of ECN path issues. 1286 Lets start to review the information the reports provide on a per 1287 source (SSRC) basis: 1289 CE Counter: The number of RTP packets received so far in the session 1290 with an ECN field set to CE (11b). 1292 ECT (0/1) Counters: The number of RTP packets received so far in the 1293 session with an ECN field set to ECT (0) and ECT (1) respectively 1294 (10b / 01b). 1296 not-ECT Counter: The number of RTP packets received so far in the 1297 session with an ECN field set to not-ECT (00b) 1299 Lost Packets counter: The number of RTP packets that are expected 1300 minus the number received. 1302 Extended Highest Sequence number: The highest sequence number seen 1303 when sending this report, but with additional bits, to handle 1304 disambiguation when wrapping the RTP sequence number field. 1306 The counters will be initiated to zero to provide value for the RTP 1307 stream sender from the very first report. After the first report the 1308 changes between the latest received and the previous one is 1309 determined by simply taking the values of the latest minus the 1310 previous one, taking field wrapping into account. This definition is 1311 also robust to packet losses, since if one report is missing, the 1312 reporting interval becomes longer, but is otherwise equally valid. 1314 In a perfect world the number of not-ECT packets received should be 1315 equal to the number sent minus the lost packets counter, and the sum 1316 of the ECT(0), ECT(1), and CE counters should be equal to the number 1317 of ECT marked packet sent. Two issues may cause a mismatch in these 1318 statistics: severe network congestion or unresponsive congestion 1319 control might cause some ECT-marked packets to be lost, and packet 1320 duplication might result in some packets being received, and counted 1321 in the statistics, multiple times (potentially with a different ECN- 1322 mark on each copy of the duplicate). 1324 The level of packet duplication included in the report can be 1325 estimated from the sum over all of fields counting received packets 1326 compared to the number of packets sent. A high level of packet 1327 duplication increases the uncertainty in the statistics, making it 1328 more difficult to draw firm conclusions about the behaviour of the 1329 network. This issue is also present with standard RTCP reception 1330 reports. 1332 Detecting clearing of ECN field: If the ratio between ECT and not-ECT 1333 transmitted in the reports has become all not-ECT or substantially 1334 changed towards not-ECT then this is clearly indication that the path 1335 results in clearing of the ECT field. 1337 Dropping of ECT packets: To determine if the packet drop ratio is 1338 different between not-ECT and ECT marked transmission requires a mix 1339 of transmitted traffic. The sender should compare if the delivery 1340 percentage (delivered / transmitted) between ECT and not-ECT is 1341 significantly different. Care must be taken if the number of packets 1342 are low in either of the categories. 1344 4.4.3. Using ECN-nonce 1346 This document offers ECN Nonce as a method of strengthening the 1347 detection of failures, and to allow senders to verify the receiver 1348 behavior. We note that it appears counter-productive for a receiver 1349 to attempt to cheat as it most likely will have negative impact on 1350 its media quality. However, certain usages of RTP may result in a 1351 situation that is more similar to TCP, i.e. where packet losses are 1352 repaired and a higher bit-rate is desirable. Thus RTP sessions that 1353 use repair mechanisms as FEC or retransmission may consider the usage 1354 of the ECN nonce to prevent cheating. 1356 5. RTCP Extensions for ECN feedback 1358 This documents defines three different RTCP extensions: one RTCP AVPF 1359 NACK Transport feedback format for urgent ECN information; one RTCP 1360 XR ECN summary report block type for regular reporting of the ECN 1361 marking information; and one additional RTCP XR report block type for 1362 ECN nonce. 1364 5.1. ECN Feedback packet 1366 This AVPF NACK feedback format is intended for usage in AVPF early or 1367 immediate feedback modes when information needs to urgently reach the 1368 sender. Thus its main use is to report on reception of an ECN-CE 1369 marked RTP packet so that the sender may perform congestion control, 1370 or to speed up the initiation procedures by rapidly reporting that 1371 the path can support ECN-marked traffic. The feedback format is also 1372 defined with reduced size RTCP [RFC5506] in mind, where RTCP feedback 1373 packets may be sent without accompanying Sender or Receiver Reports 1374 that would contain the Extended Highest Sequence number and the 1375 accumulated number of packet losses. Both are important for ECN to 1376 verify functionality and keep track of when CE marking does occur. 1378 The RTCP AVPF NACK packet starts with the common header defined by 1379 the RTP/AVPF profile [RFC4585] which is reproduced here for the 1380 reader's information: 1382 0 1 2 3 1383 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 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 |V=2|P| FMT | PT | length | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | SSRC of packet sender | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | SSRC of media source | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 : Feedback Control Information (FCI) : 1392 : : 1394 Figure 2: AVPF Feedback common header 1396 From Figure 2 it can be determined the identity of the feedback 1397 provider and for which RTP packet sender it applies. Below is the 1398 feedback information format defined that is inserted as FCI for this 1399 particular feedback messages that is identified with an FMT 1400 value=[TBA1]. 1401 0 1 2 3 1402 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 | Extended Highest Sequence Number | Lost packets counter | 1405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1406 | CE Counter | not-ECT Counter | 1407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1408 | ECT (0) Counter | ECT (1) Counter | 1409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 Figure 3: ECN Feedback Format 1413 The FCI information for the ECN Feedback format (Figure 3) are the 1414 following: 1416 Extended Highest Sequence Number: The least significant 20-bit from 1417 an Extended highest sequence number received value as defined by 1418 [RFC3550]. Used to indicate for which packet this report is valid 1419 upto. 1421 Lost Packets Counter: The cumulative number of RTP packets that the 1422 receiver expected to receive from this SSRC, minus the number of 1423 packets it actually received. This is the same as the cumulative 1424 number of packets lost defined in Section 6.4.1 of [RFC3550] 1425 except represented in 12-bit signed format, compared to 24-bit in 1426 RTCP SR or RR packets. As with the equivalent value in RTCP SR or 1427 RR packets, note that packets that arrive late are not counted as 1428 lost, and the loss may be negative if there are duplicates. 1430 CE Counter: The cumulative number of RTP packets received from this 1431 SSRC since the receiver joined the RTP session that were ECN-CE 1432 marked. The receiver should keep track of this value using a 1433 local representation that is longer than 16-bits, and only include 1434 the 16-bits with least significance. In other words, the field 1435 will wrap to 0 if more than 65535 packets has been received. 1437 ECT(0) Counter: The cumulative number of RTP packets received from 1438 this SSRC since the receiver joined the RTP session that had an 1439 ECN field value of ECT(0). The receiver should keep track of this 1440 value using a local representation that is longer than 16-bits, 1441 and only include the 16-bits with least significance. In other 1442 words, the field will wrap if more than 65535 packets have been 1443 received. 1445 ECT(1) Counter: The cumulative number of RTP packets received from 1446 this SSRC since the receiver joined the RTP session that had an 1447 ECN field value of ECT(1). The receiver should keep track of this 1448 value using a local representation that is longer than 16-bits, 1449 and only include the 16-bits with least significance. In other 1450 words, the field will wrap if more than 65535 packets have been 1451 received. 1453 not-ECT Counter: The cumulative number of RTP packets received from 1454 this SSRC since the receiver joined the RTP session that had an 1455 ECN field value of not-ECT. The receiver should keep track of 1456 this value using a local representation that is longer than 16- 1457 bits, and only include the 16-bits with least significance. In 1458 other words, the field will wrap if more than 65535 packets have 1459 been received. 1461 Each FCI block reports on a single source (SSRC). Multiple sources 1462 can be reported by including multiple RTCP feedback messages in an 1463 compound RTCP packet. The AVPF common header indicates both the 1464 sender of the feedback message and on which stream it relates to. 1466 The Counters SHALL be initiated to 0 for a new receiver. This to 1467 enable detection of CE or Packet loss already on the initial report 1468 from a specific participant. 1470 The Extended Highest sequence number and packet loss fields are both 1471 truncated in comparison to the RTCP SR or RR versions. This is to 1472 save bits as the representation is redundant unless reduced size RTCP 1473 is used in such a way that only feedback packets are transmitted, 1474 with no SR or RR in the compound RTCP packet. Due to that regular 1475 RTCP reporting will include the longer versions of the fields the 1476 wrapping issue will be less unless the packet rate of the application 1477 is so high that the fields will wrap within a regular RTCP reporting 1478 interval. In those case the feedback packet need to be sent in a 1479 compound packet together with the SR or RR packet. 1481 There is an issue with packet duplication in relation to the packet 1482 loss counter. If one avoids holding state for which sequence number 1483 has been received then the way one can count loss is to count the 1484 number of received packets and compare that to the number of packets 1485 expected. As a result a packet duplication can hide a packet loss. 1486 If a receiver is tracking the sequence numbers actually received and 1487 suppresses duplicates it provides for a more reliable packet loss 1488 indication. Reordering may also result in that packet loss is 1489 reported in one report and then removed in the next. 1491 The CE counter is actually more robust for packet duplication. 1492 Adding each received CE marked packet to the counter is not an issue. 1493 If one of the clones was CE marked that is still a indication of 1494 congestion. Packet duplication has potential impact on the ECN 1495 verification. Thus the sum of packets reported may be higher than 1496 the number sent. However, most detections are still applicable. 1498 5.2. RTCP XR Report block for ECN summary information 1500 This report block combined with RTCP SR or RR report blocks carries 1501 the same information as the ECN Feedback Packet and shall be based on 1502 the same underlying information. However, there is a difference in 1503 semantics between the feedback format and this XR version. Where the 1504 feedback format is intended to report on a CE mark as soon as 1505 possible, this extended report is for the regular RTCP report and 1506 continuous verification of the ECN functionality end-to-end. 1508 The ECN Summary report block consists of one report block header: 1509 0 1 2 3 1510 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 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 | BT | Reserved | Block Length | 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 and then followed of one or more of the following report data blocks: 1517 0 1 2 3 1518 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 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | SSRC of Media Sender | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1522 | CE Counter | not-ECT Counter | 1523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 | ECT (0) Counter | ECT (1) Counter | 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 BT: Block Type identifying the ECN summary report block. Value is 1527 [TBA2]. 1529 Reserved: All bits SHALL be set to 0 on transmission and ignored on 1530 reception. 1532 Block Length: The length of the report block. Used to indicate the 1533 number of report data blocks present in the ECN summary report. 1534 This length will always equal 3, since blocks are a fixed size. 1536 SSRC of Media Sender: The SSRC identifying the media sender this 1537 report is for. 1539 CE Counter: as in Section 5.1. 1541 ECT(0) Counter: as in Section 5.1. 1543 ECT(1) Counter: as in Section 5.1. 1545 not-ECT Counter: as in Section 5.1. 1547 The Extended Highest Sequence number and the packet loss counter for 1548 each SSRC is not present in RTCP XR report, in contrast to the 1549 feedback version. The reason is that this summary report will always 1550 be sent in a RTCP compound packet where the Extended Highest Sequence 1551 number and the accumulated number of packet losses are present in the 1552 RTCP Sender Report or Receiver Report packet's report block. 1554 5.3. RTCP XR Report Block for ECN Nonce 1556 This RTCP XR block is for ECN Nonce reporting. It consists of an 1557 initial part that contains the ECN nonce XOR sum, followed by a 1558 series of bit-vector chunks that indicate which RTP sequence numbers 1559 were lost or CE-marked, and so weren't included in the ECN nonce sum. 1560 The bit-vector uses 1 to indicate that the packet wasn't included in 1561 the ECN nonce sum and 0 for packets that where. 1563 The bit-vector is expressed using either Run-Length Encoding or 15- 1564 bit explicit bit-vectors. The whole vector is encoded using the 16- 1565 bit chunks as defined by Section 4.1.1, 4.1.2, and 4.1.3 in 1566 [RFC3611]. The Terminating Null Chunk MUST be used as padding in 1567 cases the total number of chunks would otherwise be odd and thus the 1568 report block wouldn't reach a 32-bit boundary. 1570 The ECN Nonce report block structure is the following: 1572 0 1 2 3 1573 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 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | BT |R|R|R|R|INV|RNV| Block Length | 1576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1577 | SSRC of Media Sender | 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1579 | Begin_seq | End_seq | 1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1581 | chunk 1 | chunk 2 | 1582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 : ... : 1584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1585 | chunk n-1 | chunk n | 1586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 BT: Block Type, the value identifying this block is [TBA3]. 1590 R: Bits are reserved and MUST be set to 0 on transmission and MUST be 1591 ignored on reception. 1593 Block Length: The block length of this full report block in 32-bit 1594 words minus one. The minimal report block size is 3, i.e. fixed 1595 parts (12 bytes) plus 2 chunks (4 bytes) expressed as 32-bit words 1596 (3+1) minus 1. 1598 SSRC of Media Sender SSRC of Media Sender that this report concerns 1600 INV: Initial Nonce Value. Which is the value of Nonce prior to the 1601 XOR addition of the ECN field value for the packet that start the 1602 nonce reporting interval. This first included sequence number is 1603 given by the "begin_seq" value. This to allow running 1604 calculations and only need to save nonce values at reporting 1605 boundaries. 1607 RNV: Resulting Nonce Value. The Nonce sum value resulting after 1608 having XOR the ECN field value for all packets received and not 1609 ECN-CE marked with the INV value up to the packet indicated by the 1610 "end_seq" sequence number value. 1612 begin_seq: First Sequence number this report covers. 1614 end_seq: Last RTP sequence number included in this report. 1616 chunk i: A chunk reporting on a part of bit-vector indicating if the 1617 packet was excluded from the ECN Nonce due to being lost or ECN CE 1618 marked. 1620 The Nonce sum initial value for a new media sender (new SSRC) SHALL 1621 be 00b. Otherwise the Initial value is the Nonce value calculated 1622 for the RTP packet with sequence number begin_seq -1. The initial 1623 value for the expressed reporting interval is included in the INV 1624 field. The receiver calculates the 2-bit Nonce XOR sum over all 1625 received RTP packets in the reporting interval including the one with 1626 end_seq sequence number. We note that the RTCP participant doing the 1627 Nonce sum MUST perform suppression of packet duplicates. The nonce 1628 sum will become incorrect if any duplicates are included in the sum. 1629 All packets not received or received as ECN-CE marked when 1630 constructing the ECN Nonce report MUST be explicitly marked in the 1631 bitvector. 1633 The Nonce reporting interval is RECOMMENDED to cover all the RTP 1634 packets received during the three last regular reporting intervals. 1635 This is to ensure that the sender will receive a report over all RTP 1636 packets. Failure to deliver reports that cover all the packets may 1637 be interpreted as an attempt to cheat. 1639 Two additional considerations must be made when selecting the 1640 reporting interval. First, are the MTU considerations. The packet 1641 vector and its encoding into chunks results in a variable sized 1642 report. The size depends on two main factors, the number of packets 1643 to report on and the frequency of bit-value changes in the vector. 1644 The reporting interval may need to be shortened to two or even one 1645 reporting interval if the resulting ECN nonce report becomes too big 1646 to fit into the RTCP packet. 1648 Secondly, the RTP sequence number can easily wrap and that needs to 1649 be considered when they are handled. The report SHALL NOT report on 1650 more than 32768 consecutive packets. The last sequence number is the 1651 extended sequence number that is equal too or smaller (less than 1652 65535 packets) than the value present in the Receiver Reports 1653 "extended highest sequence number received" field. The "first 1654 sequence number" value is thus an extended sequence number which is 1655 smaller than the "last sequence number". If there is a wrap between 1656 the first sequence number and the last, i.e. if the first sequence 1657 number is greater than the last sequence number (when seen as 16-bit 1658 unsigned integers), this needs to included in the calculation. If an 1659 application is having these issues, the frequency of the regular RTCP 1660 reporting should be modified by ensuring that the application chooses 1661 appropriate settings for the minimum RTCP reporting interval 1662 parameters. 1664 Both the ECN-CE and packet loss information is structured as bit 1665 vectors where the first bit represents the RTP packet with the 1666 sequence number equal to the First Sequence number. The bit-vector 1667 will contain values representing all packets up to and including the 1668 one in the "end_seq" field. The chunk mechanism used to represent 1669 the bit-vector in an efficient way may appear longer upon reception 1670 if an explicit bit-vector is used as the last chunk. Bit-values 1671 representing packets with higher sequence number (modulo 16) than 1672 "end_seq" are not valid and SHALL be ignored. 1674 The produced bit-vector is encoded using chunks. The chunks are any 1675 of the three types defined in [RFC3611], Run Length Chunk (Section 1676 4.1.1 of [RFC3611]), Bit Vector Chunk (Section 4.1.2 of [RFC3611]), 1677 or Terminating Null Chunk (Section 4.1.3 of [RFC3611]). Where the 1678 Terminating Null Chunk may only appear as the last chunk, and only in 1679 cases where the number of chunks otherwise would be odd. 1681 6. Processing RTCP ECN Feedback in RTP Translators and Mixers 1683 RTP translators and mixers that support ECN feedback are required to 1684 process, and potentially modify or generate, RTCP packets for the 1685 translated and/or mixed streams. 1687 6.1. Fragmentation and Reassembly in Translators 1689 An RTP translator may fragment or reassemble RTP data packets without 1690 changing the media encoding, and without reference to the congestion 1691 state of the networks it bridges. An example of this might be to 1692 combine packets of a voice-over-IP stream coded with one 20ms frame 1693 per RTP packet into new RTP packets with two 20ms frames per packet, 1694 thereby reducing the header overheads and so stream bandwidth, at the 1695 expense of an increase in latency. If multiple data packets are re- 1696 encoded into one, or vice versa, the RTP translator MUST assign new 1697 sequence numbers to the outgoing packets. Losses in the incoming RTP 1698 packet stream may also induce corresponding gaps in the outgoing RTP 1699 sequence numbers. An RTP translator MUST rewrite RTCP packets to 1700 make the corresponding changes to their sequence numbers, and to 1701 reflect the impact of the fragmentation or reassembly. This section 1702 describes how that rewriting is to be done for RTCP ECN feedback 1703 packets. Section 7.2 of [RFC3550] describes general procedures for 1704 other RTCP packet types. 1706 RTCP ECN feedback packets (Section 5.1) contain six fields that are 1707 rewritten in an RTP translator that fragments or reassembles packets: 1708 the extended highest sequence number, the lost packets counter, the 1709 CE counter, and not-ECT counter, the ECT(0) counter, and the ECT(1) 1710 counter. The RTCP XR report block for ECN summary information 1711 (Section 5.2) includes a subset of these fields excluding the 1712 extended highest sequence number and lost packets counter. The 1713 procedures for rewriting these fields are the same for both types of 1714 RTCP ECN feedback packet. 1716 When receiving an RTCP ECN feedback packet, an RTP translator first 1717 determines the range of packets to which the report corresponds. The 1718 extended highest sequence number in the RTCP ECN feedback packet (or 1719 in the RTCP SR/RR packet contained within the compound packet, in the 1720 case of RTCP XR ECN summary reports) specifies the end sequence 1721 number of the range. For the first RTCP ECN feedback packet 1722 received, the initial extended sequence number of the range may be 1723 determined by subtracting the sum of the lost packets counter, the CE 1724 counter, the not-ECT counter, the ECT(0) counter and the ECT(1) 1725 counter from the extended highest sequence number (this will be 1726 inaccurate if there is packet duplication). For subsequent RTCP ECN 1727 feedback packets, the starting sequence number may be determined as 1728 being one after the extended highest sequence number of the previous 1729 RTCP ECN feedback packet received from the same SSRC. These values 1730 are in the sequence number space of the translated packets. 1732 Based on its knowledge of the translation process, the translator 1733 determines the sequence number range for the corresponding original, 1734 pre-translation, packets. The extended highest sequence number in 1735 the RTCP ECN feedback packet is rewritten to match the final sequence 1736 number in the pre-translation sequence number range. 1738 The translator then determines the ratio, R, of the number of packets 1739 in the translated sequence number space (numTrans) to the number of 1740 packets in the pre-translation sequence number space (numOrig) such 1741 that R = numTrans / numOrig. The counter values in the RTCP ECN 1742 feedback report are then scaled by dividing each of them by R. For 1743 example, if the translation process combines two RTP packets into 1744 one, then numOrig will be twice numTrans, giving R=0.5, and the 1745 counters in the translated RTCP ECN feedback packet will be twice 1746 those in the original. 1748 The ratio, R, may have a value that leads to non-integer multiples of 1749 the counters when translating the RTCP packet. For example, a VoIP 1750 translator that combines two adjacent RTP packets into one if they 1751 contain active speech data, but passes comfort noise packets 1752 unchanged, would have an R values of between 0.5 and 1.0 depending on 1753 the amount of active speech. Since the counter values in the 1754 translated RTCP report are integer values, rounding will be necessary 1755 in this case. 1757 When rounding counter values in the translated RTCP packet, the 1758 translator should try to ensure that they sum to the number of RTP 1759 packets in the pre-translation sequence number space (numOrig). The 1760 translator should also try to ensure that no non-zero counter is 1761 rounded to a zero value, since that will lose information that a 1762 particular type of event has occurred. It is recognised that it may 1763 be impossible to satisfy both of these constraints; in such cases, it 1764 is better to ensure that no non-zero counter is mapped to a zero 1765 value, since this preserves congestion adaptation and helps the RTCP- 1766 based ECN initiation process. 1768 It should be noted that scaling the RTCP counter values in this way 1769 is meaningful only on the assumption that the level of congestion in 1770 the network is related to the number of packets being sent. This is 1771 likely to be a reasonable assumption in the type of environment where 1772 RTP translators that fragment or reassemble packets are deployed, as 1773 their entire purpose is to change the number of packets being sent to 1774 adapt to known limitations of the network, but is not necessarily 1775 valid in general. 1777 The rewritten RTCP ECN feedback report is sent from the other side of 1778 the translator to that which it arrived (as part of a compound RTCP 1779 packet containing other translated RTCP packets, where appropriate). 1781 The RTCP XR Report Block for the ECN nonce is used to convey the ECN 1782 nonce and an explicit bit vector of which packets were ECN marked. 1783 It is not meaningful to translate this report block, since it relates 1784 to particular packets that only exist on one side of the translator. 1785 An RTP translator MAY silently drop ECN nonce report blocks when 1786 translating RTCP packets, or it MAY consume ECN nonce report blocks 1787 received from downstream, and generate its own ECN nonce reports to 1788 send upstream, based on its reception of the media stream. If the 1789 RTP translator is a party to the signalling exchange, ECN nonce 1790 SHOULD NOT be negotiated. 1792 6.2. Generating RTCP ECN Feedback in Media Transcoders 1794 An RTP translator that acts as a media transcoder cannot directly 1795 forward RTCP packets corresponding to the transcoded stream, since 1796 those packets will relate to the non-transcoded stream, and will not 1797 be useful in relation to the transcoded RTP flow. Such a transcoder 1798 will need to interpose itself into the RTCP flow, acting as a proxy 1799 for the receiver to generate RTCP feedback in the direction of the 1800 sender relating to the pre-transcoded stream, and acting in place of 1801 the sender to generate RTCP relating to the transcoded stream, to be 1802 sent towards the receiver. This section describes how this proxying 1803 is to be done for RTCP ECN feedback packets. Section 7.2 of 1804 [RFC3550] describes general procedures for other RTCP packet types. 1806 An RTP translator acting as a media transcoder in this manner does 1807 not have its own SSRC, and hence is not visible to other entities at 1808 the RTP layer. RTCP ECN feedback packets, RTCP XR report blocks for 1809 ECN summary information, and RTCP XR report blocks for the ECN nonce 1810 that are received from downstream relate to the translated stream, 1811 and so must be processed by the translator as if it were the original 1812 media source. These reports drive the congestion control loop and 1813 media adaptation between the translator and the downstream receiver. 1814 If there are multiple downstream receivers, a logically separate 1815 transcoder instance must be used for each receiver, and must process 1816 RTCP ECN feedback and summary reports independently to the other 1817 transcoder instances. An RTP translator acting as a media transcoder 1818 in this manner MUST NOT forward RTCP ECN feedback packets, RTCP XR 1819 ECN summary reports, or RTCP XR ECN nonce reports from downstream 1820 receivers in the upstream direction. 1822 An RTP translator acting as a media transcoder will generate RTCP 1823 reports upstream towards the original media sender, based on the 1824 reception quality of the original media stream at the translator. 1825 The translator will run a separate congestion control loop and media 1826 adaptation between itself and the media sender for each of its 1827 downstream receivers, and must generate RTCP ECN feedback packets and 1828 RTCP XR ECN summary reports (and RTCP XR ECN nonce reports, if 1829 desired) for that congestion control loop using the SSRC of that 1830 downstream receiver. 1832 6.3. Generating RTCP ECN Feedback in Mixers 1834 An RTP mixer terminates one-or-more RTP flows, combines them into a 1835 single outgoing media stream, and transmits that new stream as a 1836 separate RTP flow. A mixer has its own SSRC, and is visible to other 1837 participants in the session at the RTP layer. 1839 An ECN-aware RTP mixer must generate RTCP ECN feedback packets and 1840 RTCP XR report blocks for ECN summary information relating to the RTP 1841 flows it terminates, in exactly the same way it would if it were an 1842 RTP receiver. An ECN-aware RTP mixer can optionally generate RTCP XR 1843 report blocks containing ECN nonce information. These reports form 1844 part of the congestion control loop between the mixer and the media 1845 senders generating the streams it is mixing. A separate control loop 1846 runs between each sender and the mixer. 1848 An ECN-aware RTP mixer will negotiate and initiate the use of ECN on 1849 the mixed flows it generates, and will accept and process RTCP ECN 1850 feedback reports, RTCP XR report blocks for ECN, and RTCP XR report 1851 blocks for the ECN nonce relating to those mixed flows as if it were 1852 a standard media sender. A congestion control loop runs between the 1853 mixer and its receivers, driven in part by the ECN reports received. 1855 An RTP mixer MUST NOT forward RTCP ECN feedback packets, RTCP XR ECN 1856 summary reports, or RTCP XR ECN nonce reports from downstream 1857 receivers in the upstream direction. 1859 7. Implementation considerations 1861 To allow the use of ECN with RTP over UDP, the RTP implementation 1862 must be able to set the ECT bits in outgoing UDP datagrams, and must 1863 be able to read the value of the ECT bits on received UDP datagrams. 1864 The standard Berkeley sockets API pre-dates the specification of ECN, 1865 and does not provide the functionality which is required for this 1866 mechanism to be used with UDP flows, making this specification 1867 difficult to implement portably. 1869 8. IANA Considerations 1871 Note to RFC Editor: please replace "RFC XXXX" below with the RFC 1872 number of this memo, and remove this note. 1874 8.1. SDP Attribute Registration 1876 Following the guidelines in [RFC4566], the IANA is requested to 1877 register one new SDP attribute: 1879 o Contact name, email address and telephone number: Authors of 1880 RFCXXXX 1882 o Attribute-name: ecn-capable-rtp 1884 o Type of attribute: media-level 1886 o Subject to charset: no 1888 This attribute defines the ability to negotiate the use of ECT (ECN 1889 capable transport). This attribute should be put in the SDP offer if 1890 the offering party wishes to receive an ECT flow. The answering 1891 party should include the attribute in the answer if it wish to 1892 receive an ECT flow. If the answerer does not include the attribute 1893 then ECT MUST be disabled in both directions. 1895 8.2. AVPF Transport Feedback Message 1897 A new RTCP Transport feedback message needs a FMT code point 1898 assigned. ... 1900 8.3. RTCP XR Report blocks 1902 Two new RTCP XR report blocks needs to be assigned block type codes. 1904 8.4. STUN attribute 1906 A new STUN attribute in the Comprehension-optional range needs to be 1907 assigned... 1909 8.5. ICE Option 1911 A new ICE option "rtp+ecn" is registered in the non-existing registry 1912 which needs to be created. 1914 9. Security Considerations 1916 The usage of ECN with RTP over UDP as specified in this document has 1917 the following known security issues that needs to be considered. 1919 External threats to the RTP and RTCP traffic: 1921 Denial of Service affecting RTCP: For an attacker that can modify 1922 the traffic between the media sender and a receiver can achieve 1923 either of two things. 1. Report a lot of packets as being 1924 Congestion Experience marked, thus forcing the sender into a 1925 congestion response. 2. Ensure that the sender disable the usage 1926 of ECN by reporting failures to receive ECN by changing the 1927 counter fields. The Issue, can also be accomplished by injecting 1928 false RTCP packets to the media sender. Reporting a lot of CE 1929 marked traffic is likely the more efficient denial of service tool 1930 as that may likely force the application to use lowest possible 1931 bit-rates. The prevention against an external threat is to 1932 integrity protect the RTCP feedback information and authenticate 1933 the sender of it. 1935 Information leakage: The ECN feedback mechanism exposes the 1936 receivers perceived packet loss, what packets it considers to be 1937 ECN-CE marked and its calculation of the ECN-none. This is mostly 1938 not considered sensitive information. If considered sensitive the 1939 RTCP feedback shall be encrypted. 1941 Changing the ECN bits An on-path attacker that see the RTP packet 1942 flow from sender to receiver and who has the capability to change 1943 the packets can rewrite ECT into ECN-CE thus forcing the sender or 1944 receiver to take congestion control response. This denial of 1945 service against the media quality in the RTP session is impossible 1946 for en end-point to protect itself against. Only network 1947 infrastructure nodes can detect this illicit re-marking. It will 1948 be mitigated by turning off ECN, however, if the attacker can 1949 modify its response to drop packets the same vulnerability exist. 1951 Denial of Service affecting the session set-up signalling: If an 1952 attacker can modify the session signalling it can prevent the 1953 usage of ECN by removing the signalling attributes used to 1954 indicate that the initiator is capable and willing to use ECN with 1955 RTP/UDP. This attack can be prevented by authentication and 1956 integrity protection of the signalling. We do note that any 1957 attacker that can modify the signalling has more interesting 1958 attacks they can perform than prevent the usage of ECN, like 1959 inserting itself as a middleman in the media flows enabling wire- 1960 tapping also for an off-path attacker. 1962 The following are threats that exist from misbehaving senders or 1963 receivers: 1965 Receivers cheating A receiver may attempt to cheat and fail to 1966 report reception of ECN-CE marked packets. The benefit for a 1967 receiver cheating in its reporting would be to get an unfair bit- 1968 rate share across the resource bottleneck. It is far from certain 1969 that a receiver would be able to get a significant larger share of 1970 the resources. That assumes a high enough level of aggregation 1971 that there are flows to acquire shares from. The risk of cheating 1972 is that failure to react to congestion results in packet loss and 1973 increased path delay. To mitigate the risk of cheating receivers 1974 the solution include ECN-Nonce that makes it probabilistically 1975 unlikely that a receiver can cheat for more than a few packets 1976 before being found out. See [RFC3168] and [RFC3540] for more 1977 discussion. 1979 Receivers misbehaving: A receiver may prevent the usage of ECN in an 1980 RTP session by reporting itself as non ECN capable or simple 1981 provide invalid ECN-nonce values. Thus forcing the sender to turn 1982 off usage of ECN. In a point-to-point scenario there is little 1983 incentive to do this as it will only affect the receiver. Thus 1984 failing to utilise an optimisation. For multi-party session there 1985 exist some motivation why a receiver would misbehave as it can 1986 prevent also the other receivers from using ECN. As an insider 1987 into the session it is difficult to determine if a receiver is 1988 misbehaving or simply incapable, making it basically impossible in 1989 the incremental deployment phase of ECN for RTP usage to determine 1990 this. If additional information about the receivers and the 1991 network is known it might be possible to deduce that a receiver is 1992 misbehaving. If it can be determined that a receiver is 1993 misbehaving, the only response is to exclude it from the RTP 1994 session and ensure that is doesn't any longer have any valid 1995 security context to affect the session. 1997 Misbehaving Senders: The enabling of ECN gives the media packets a 1998 higher degree of probability to reach the receiver compared to 1999 not-ECT marked ones. However, this is no magic bullet and failure 2000 to react to congestion will most likely only slightly delay a 2001 buffer under-run, in which its session also will experience packet 2002 loss and increased delay. There are some chance that the media 2003 senders traffic will push other traffic out of the way without 2004 being effected to negatively. However, we do note that a media 2005 sender still needs to implement congestion control functions to 2006 prevent the media from being badly affected by congestion events. 2007 Thus the misbehaving sender is getting a unfair share. This can 2008 only be detected and potentially prevented by network monitoring 2009 and administrative entities. See Section 7 of [RFC3168] for more 2010 discussion of this issue. 2012 ECN as covert channel: As the ECN fields two bits can be set to two 2013 different values for ECT, it is possible to use ECN as a covert 2014 channel with a possible bit-rate of one or two bits per packet. 2015 For more discussion of this issue please see 2016 [I-D.ietf-tsvwg-ecn-tunnel]. 2018 We note that the end-point security functions needs to prevent an 2019 external attacker from affecting the solution easily are source 2020 authentication and integrity protection. To prevent what information 2021 leakage there can be from the feedback encryption of the RTCP is also 2022 needed. For RTP there exist multiple solutions possible depending on 2023 the application context. Secure RTP (SRTP) [RFC3711] does satisfy 2024 the requirement to protect this mechanism despite only providing 2025 authentication if a entity is within the security context or not. 2026 IPsec [RFC4301] and DTLS [RFC4347] can also provide the necessary 2027 security functions. 2029 The signalling protocols used to initiate an RTP session also needs 2030 to be source authenticated and integrity protected to prevent an 2031 external attacker from modifying any signalling. Here an appropriate 2032 mechanism to protect the used signalling needs to be used. For SIP/ 2033 SDP ideally S/MIME [RFC5751] would be used. However, with the 2034 limited deployment a minimal mitigation strategy is to require use of 2035 SIPS (SIP over TLS) [RFC3261] [RFC5630] to at least accomplish hop- 2036 by-hop protection. 2038 We do note that certain mitigation methods will require network 2039 functions. 2041 10. Examples of SDP Signalling 2043 (tbd) 2045 11. Open Issues 2047 As this draft is under development some known open issues exist and 2048 are collected here. Please consider them and provide input. 2050 1. The negotiation and directionality attribute is going to need 2051 some consideration for multi-party sessions when readonly 2052 capability might be sufficient to enable ECN for all incoming 2053 streams. However, it would beneficial to know if no potential 2054 sender support setting ECN. 2056 2. Consider initiation optimizations that allows for multi SSRC 2057 sender nodes to still have rapid usage of ECN. 2059 12. References 2061 12.1. Normative References 2063 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2064 Requirement Levels", BCP 14, RFC 2119, March 1997. 2066 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2067 of Explicit Congestion Notification (ECN) to IP", 2068 RFC 3168, September 2001. 2070 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2071 Jacobson, "RTP: A Transport Protocol for Real-Time 2072 Applications", STD 64, RFC 3550, July 2003. 2074 [RFC3611] Friedman, T., Caceres, R., and A. Clark, "RTP Control 2075 Protocol Extended Reports (RTCP XR)", RFC 3611, 2076 November 2003. 2078 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 2079 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2081 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 2082 (ICE): A Protocol for Network Address Translator (NAT) 2083 Traversal for Offer/Answer Protocols", RFC 5245, 2084 April 2010. 2086 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 2087 Friendly Rate Control (TFRC): Protocol Specification", 2088 RFC 5348, September 2008. 2090 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 2091 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 2092 October 2008. 2094 12.2. Informative References 2096 [I-D.ietf-avt-rtp-no-op] 2097 Andreasen, F., "A No-Op Payload Format for RTP", 2098 draft-ietf-avt-rtp-no-op-04 (work in progress), May 2007. 2100 [I-D.ietf-tsvwg-ecn-tunnel] 2101 Briscoe, B., "Tunnelling of Explicit Congestion 2102 Notification", draft-ietf-tsvwg-ecn-tunnel-08 (work in 2103 progress), March 2010. 2105 [I-D.zimmermann-avt-zrtp] 2106 Zimmermann, P., Johnston, A., and J. Callas, "ZRTP: Media 2107 Path Key Agreement for Unicast Secure RTP", 2108 draft-zimmermann-avt-zrtp-22 (work in progress), 2109 June 2010. 2111 [RFC2974] Handley, M., Perkins, C., and E. Whelan, "Session 2112 Announcement Protocol", RFC 2974, October 2000. 2114 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 2115 A., Peterson, J., Sparks, R., Handley, M., and E. 2116 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 2117 June 2002. 2119 [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model 2120 with Session Description Protocol (SDP)", RFC 3264, 2121 June 2002. 2123 [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit 2124 Congestion Notification (ECN) Signaling with Nonces", 2125 RFC 3540, June 2003. 2127 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2128 Video Conferences with Minimal Control", STD 65, RFC 3551, 2129 July 2003. 2131 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 2132 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 2133 RFC 3711, March 2004. 2135 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 2136 Internet Protocol", RFC 4301, December 2005. 2138 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2139 Congestion Control Protocol (DCCP)", RFC 4340, March 2006. 2141 [RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 2142 Security", RFC 4347, April 2006. 2144 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 2145 Description Protocol", RFC 4566, July 2006. 2147 [RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 2148 "Extended RTP Profile for Real-time Transport Control 2149 Protocol (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, 2150 July 2006. 2152 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 2153 RFC 4960, September 2007. 2155 [RFC5124] Ott, J. and E. Carrara, "Extended Secure RTP Profile for 2156 Real-time Transport Control Protocol (RTCP)-Based Feedback 2157 (RTP/SAVPF)", RFC 5124, February 2008. 2159 [RFC5506] Johansson, I. and M. Westerlund, "Support for Reduced-Size 2160 Real-Time Transport Control Protocol (RTCP): Opportunities 2161 and Consequences", RFC 5506, April 2009. 2163 [RFC5630] Audet, F., "The Use of the SIPS URI Scheme in the Session 2164 Initiation Protocol (SIP)", RFC 5630, October 2009. 2166 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 2167 Mail Extensions (S/MIME) Version 3.2 Message 2168 Specification", RFC 5751, January 2010. 2170 [RFC5760] Ott, J., Chesterfield, J., and E. Schooler, "RTP Control 2171 Protocol (RTCP) Extensions for Single-Source Multicast 2172 Sessions with Unicast Feedback", RFC 5760, February 2010. 2174 Authors' Addresses 2176 Magnus Westerlund 2177 Ericsson 2178 Farogatan 6 2179 SE-164 80 Kista 2180 Sweden 2182 Phone: +46 10 714 82 87 2183 Email: magnus.westerlund@ericsson.com 2184 Ingemar Johansson 2185 Ericsson 2186 Laboratoriegrand 11 2187 SE-971 28 Lulea 2188 SWEDEN 2190 Phone: +46 73 0783289 2191 Email: ingemar.s.johansson@ericsson.com 2193 Colin Perkins 2194 University of Glasgow 2195 Department of Computing Science 2196 Glasgow G12 8QQ 2197 United Kingdom 2199 Email: csp@csperkins.org 2201 Piers O'Hanlon 2202 University College London 2203 Computer Science Department 2204 Gower Street 2205 London WC1E 6BT 2206 United Kingdom 2208 Email: p.ohanlon@cs.ucl.ac.uk 2210 Ken Carlberg 2211 G11 2212 1600 Clarendon Blvd 2213 Arlington VA 2214 USA 2216 Email: carlberg@g11.org.uk