idnits 2.17.1 draft-carlberg-tsvwg-ecn-reactions-04.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 12 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 13 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 163 instances of too long lines in the document, the longest one being 67 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (Feb 25, 2013) is 4077 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 94, but not defined == Missing Reference: 'RFC4828' is mentioned on line 159, but not defined == Missing Reference: 'RFC3448' is mentioned on line 186, but not defined ** Obsolete undefined reference: RFC 3448 (Obsoleted by RFC 5348) == Missing Reference: 'RFC5348' is mentioned on line 187, but not defined == Missing Reference: 'RFC5104' is mentioned on line 194, but not defined == Missing Reference: 'RFC4867' is mentioned on line 194, but not defined == Unused Reference: 'Goog1' is defined on line 533, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TSVWG K. Carlberg 3 Internet-Draft G11 4 Intended Status: Informational P. O'Hanlon 5 Expires: August 25, 2013 UCL 6 Feb 25, 2013 8 Reactions to Signaling from ECN Support for RTP/RTCP 9 11 Status of this Memo 13 This Internet-Draft is submitted in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF). Note that other groups may also distribute working 18 documents as Internet-Drafts. The list of current Internet-Drafts is at 19 http://datatracker.ietf.org/drafts/current/. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference material 24 or to cite them other than as "work in progress." 26 This Internet-Draft will expire on August 25, 2013. 28 Copyright Notice 30 Copyright (c) 2013 IETF Trust and the persons identified as the 31 document authors. All rights reserved. 33 This document is subject to BCP 78 and the IETF Trust's Legal 34 Provisions Relating to IETF Documents 35 (http://trustee.ietf.org/license-info) in effect on the date of 36 publication of this document. Please review these documents 37 carefully, as they describe your rights and restrictions with respect 38 to this document. Code Components extracted from this document must 39 include Simplified BSD License text as described in Section 4.e of 40 the Trust Legal Provisions and are provided without warranty as 41 described in the Simplified BSD License. 43 Abstract 45 This document presents an examination of various responses to Congestion 46 Experience (CE) notifications by real time applications that have 47 negotiated end-to-end support of Explicit Congestion Notification (ECN). 48 This document is a follow-on effort of [rfc6679], which specifies the 49 signaling used to provide ECN support for RTP/RTCP flows. 51 1. Introduction 53 This document presents an examination of various responses to Congestion 54 Experience (CE) notifications by real time applications that have 55 negotiated end-to-end support of Explicit Congestion Notification (ECN). 56 [rfc6679] defines the signaling for support of ECN by RTP based sessions 57 and also covers the case where a et of nodes do not respond to CE 58 notifications. A more detailed discussion about how back-off algorithms 59 can be achieved, as well as other potential reactions, is viewed as out 60 of scope of that document and may be addressed by a companion document. 62 1.1 Background 64 ECN is a mechanism used to explicitly signal the presence of congestion 65 without relying on packet loss. It was initially designed using a dual 66 layer signaling model; negotiation and feedback at the transport layer, 67 and downstream notification of congestion at the network layer. For IP, 68 a new two bit field was used to both indicate the successful negotiated 69 support for ECN signaling, as well as indicate the presence of 70 congestion via the CE flag. In the case of TCP [rfc3168], a new TCP 71 header flag was defined that provides upstream end-to-end indication of 72 congestion occurring somewhere along the downstream path. 74 There should be no difference in congestion response if ECN-CE marks or 75 packet drops are detected. However it is noted that there MAY be other 76 reactions to ECN-CE specified in the future. Such an alternative 77 reaction MUST be specified and considered to be safe for deployment 78 under any restrictions specified. We specify such an alternative in 79 this document. 81 With respect to ECN for TCP, [rfc3168] specifies an indication of 82 congestion, but it does so once per Round Trip Time (RTT). [rfc6679] is 83 an effort that proposes a finer grained notification reflecting a more 84 accurate indication of the number of ECN marked packets received within 85 one RTT. It should be noted that there is also other on going work to 86 provide more accurate ECN feedback information for TCP 87 [draft-tcpm-accecn-reqs]. 89 1.2 Terminology and Abbreviations 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in RFC2119 [RFC2119]. 95 2. Issues 96 The initial discussions and presentation of [draft-rtp-ecn] produced a 97 consensus that the specification of signaling was to be done within the 98 AVTcore working group, and any subsequent discussion on end-to-end 99 reactions to the signaling would be accomplished in the Transport 100 Services (TSV) working group. This draft satisfies the latter effort. 102 Another issue that needs to be recognized is that the reactions to CE in 103 the context of [rfc6679] are the responsibility of the application. 104 This is in contrast to ECN support for TCP, where explicit signaled 105 feedback of, and reaction to, CE is kept transparent to the application. 106 The issue of placing the feedback responsibility in the application is 107 that each application needs to add specific support for that reaction. 108 On the other hand, multiple reactions may be considered by the 109 application. For this reason, [rfc6679] states the need for a default 110 congestion control reaction that MUST be supported. Section 3 through 5 111 expands on this topic. 113 3. Congestion Control Algorithms 115 The transport of any data flow across the Internet produces a need for some 116 form of congestion control to attain a suitable share of the capacity of the 117 path through a network. Most of the existing work on realtime congestion 118 control algorithms has been rooted in TCP-friendly approaches but with smoother 119 adaptation cycles. TCP congestion control is unsuitable for interactive media 120 for a number of reasons including the fact that it is loss-based so it 121 maximizes the latency on a path, it changes its transmit rate to quickly 122 for multimedia, and favors reliability over timeliness. In the case of 123 real time media transport, one requires: 125 Smoother rate variation: (than for bulk data) to accommodate 126 the underlying media flow's characteristics. 128 Low latency: Maintaining latencies sufficient to be usable, where 150ms 129 is understood to be a good target [ITU.G114.2003]. 131 Burst handling: Ability to handle bursts due to the nature of the 132 media and codec (e.g. I-frames etc) 134 3.1 TCP Friendly Rate Control (TFRC) 136 TFRC has a smoother response to congestion than TCP-like approaches, 137 thus making it more suitable for real-time interactive multimedia 138 applications. It has been cited in a number of other documents within 139 the IETF for use with UDP and media flows [rfc3714, bcp145] and is 140 seeing full and partial deployment in related solutions such as 141 Empathy/Farsight, and GoogleTalk [goog1]. 143 However it should be noted that TFRC is only recommended for real-time 144 media use with ECN response. TFRC is not recommended for non-ECN paths 145 due to its loss based operation which leads to full queues with 146 maximised latencies. It is assumed that ECN markings will usually occur 147 with lower queue occupancy and thus lower latency. However it is 148 understood that ECN marks may not provide for sufficiently low latencies 149 in some situations so other congestion control solutions would be 150 preferable. 152 [rfc4342] specifies the profile for TFRC for use in the Datagram 153 Congestion Control Protocol (DCCP) [rfc4340] for a half connection. A 154 DCCP half connection is defined as application data sent downstream with 155 corresponding acknowledgements sent upstream. These half-connections 156 can be realized in the form of one-way pre-recoded media, one-way live 157 media, or two-way interactive. A perceived drawback in this profile 158 concerns its application to interactive media that use small packets. 159 [RFC4828] is an experimental protocol defining a variation of TFRC used 160 to address this drawback and achieve the same bandwidth as a TCP flow 161 using packets of size 1500 bytes. 163 [rfc6679] is an standard that specifies how RTP flows can be supported 164 using the RTP/AVPF profile and the general RTP header extension 165 mechanism. 167 3.2 Related Work 169 3.2.1 3GPP 171 Outside of this previous and on-going work with TFRC, it is understood 172 that some parties have issues with the behavior of TFRC under certain 173 conditions. A notable mention of this is made in the 3GPP's document on 174 IP Multimedia Subsystem (IMS) Media handling and interaction [TR26.114], 175 where it is mentioned: 177 "Note that for IMS networks, which normally have nonzero packet loss and 178 fairly long round-trip delay, the amount of bitrate reduction specified 179 in RFC 3448 is generally too restrictive for video and may, if used as 180 specified, result in very low video bitrates already at (for IMS) 181 moderate packet loss rates." 183 Though it is unclear exactly what the 3GPP community consider as too 184 restrictive and whether some alteration of the response may be suitable. 185 It should be noted that the 3GPP document only referred to an older 186 version of TFRC defined in [RFC3448]. Given that the current version 187 of TFRC [RFC5348] has made significant changes to the idle and data-limited responses it is unclear whether their assessment is relevant 188 to current TFRC implementations. 190 Furthermore the specification [TR26.114] only outlines a rudimentary 191 approach to congestion control, providing an example of a 60% back-off 192 reaction to loss within an RTCP reporting period. The proposed signalling 193 employs Temporary Maximum Media Stream Bit Rate Request (TMMBR) 194 [RFC5104] and Codec Mode Request (CMR) [RFC4867] for video and audio 195 respectively, which would only provide for very basic rate control 196 if used as specified. We note that [TR26.114] specifies terminal 197 behavior, while [TS36.300] specifies base station behaviour, though 198 neither specify any standardised congestion control approach. 200 It is understood that there are a number of proprietary and patented 201 approaches that provide more sophisticated response in the case of 202 3G/LTE, but since these are neither endorsed nor standardized this 203 document advocates a standardized approach such as TFRC. 205 We also acknowledge that there are many congestion control algorithms 206 available for implementers to choose from, with a subset that are 207 specifically suited to real time media transmission. However, given a 208 variety of real time applications and their various characteristics 209 (sender-only broadcast, interactive unicast, etc), we need to expand the 210 notion of how back-off can be achieved. Hence, the focus needs to be on 211 an output that would resemble the characteristics of TFRC. 213 3.2.2 RTCweb 215 Within the RTCweb Working Group the need for a more media friendly 216 congestion control mechanism has been made apparent. Currently, TFRC is 217 perceived as having deficiencies (e.g. its loss-based design, lack of 218 cross-stream congestion control functionality etc) that make it an 219 incomplete or insufficient solution for the envisioned RTCWEB media 220 flows. The RTP Media Congestion Avoidance Techniques (rmcat) working 221 group has now been formed which aims to lead to the formation of a 222 working group on these issues. The group aims to develop one or more 223 congestion control algorithms, associated extensions, and evaluation 224 criteria. Furthermore it has been proposed that certain practices, such 225 as 'circuit-breaker' conditions, to provide operational limits on 226 congestion control algorithms, and feedback messages, may be tackled in 227 other groups such as AVTCORE and AVTEXT respectively. 229 Thus there is some movement to attempt to develop new algorithms better 230 suited to media transport, but these efforts will clearly take a 231 considerable time to reach fruition. 233 3.3 ECN response 235 As mentioned above and in accordance to [rfc3168], the actual response 236 to the reception of an ECN-CE marked packet MUST normally be the same as 237 that of a lost packet. However there are a number of contexts where one 238 may also be interested in more varied approaches. We expand on this in 239 Section 5 below. 241 4. Application Layer Congestion Response 243 Whilst the congestion control algorithm may decide to alter the rate at 244 which the application should operate, in the case of media applications 245 this process is not as straightforward as the case of bulk data. The 246 different media engines and codecs in use may only have limited 247 adaptation ranges, thus, this limitation needs to be a consideration 248 when adapting the rate. Furthermore the application needs to be aware 249 of the capability of the specific codecs in terms of their ability to 250 switch configuration mid-stream (without loss of fidelity), which may 251 impose further limits on the modes of operation. 253 One approach for achieving a lower generation of data is through reduced 254 sampling of the media (e.g., voice or video). In the case of video, 255 this may also involve slower frame rates. Specific recommendations that 256 describe how applications should respond to congestion in the context of 257 supporting the algorithmic characteristics of a congestion control 258 algorithm are outside the scope of this document. 260 5. Other Reactions 262 In addition to the activation of congestion control algorithm, other 263 reactions can be used or leveraged by an application in response to CE. 264 We divide these other potential reactions into three categories: 265 signaling, fault tolerance, and reduction. In the first two cases, we 266 note that these other reactions are considered symmetric because they 267 require downstream peer support. We also point out that activation of 268 other reactions represents an example of an on-demand and as-needed 269 approach in responding to CE. 271 In each case, we discuss issues that should be considered when 272 contemplating a different reaction in the presence of CE feedback. 274 5.1 Signaling 276 5.1.1 RSVP 278 The resource Reservation Protocol (RSVP) can be used to signal a desired 279 set of path characteristics (e.g., bandwidth, delay) in response to CE 280 feedback [rfc2205]. Its operation is based on the use of PATH messages 281 sent downstream hop-by-hop from the source to a destination that specify 282 requested forwarding characteristics. In return, the destination sends 283 a hop-by-hop RESV message upstream towards the source confirming the 284 resources that have been reserved for that flow. 286 [rfc3181] defines a priority policy element that specifies both an 287 allocation and defending priority. This dual specification supports the 288 use of preemption of existing reservations. [draft-priority-rsvp] is a 289 work-in-progress that defines a new policy element that only conveys 290 priority during reservation establishment. This latter effort also 291 presents several reservation models, including one that describes 292 engineered resources set aside for priority users. 294 5.1.1.1 Issues 296 As discussed in [rfc-3583], RSVP presents a difficult challenge of 297 establishing state and effectively and efficiently migrating it during 298 roaming in mobile environments. Its soft state design allows the 299 protocol to attempt re-establishment of reserved resources along new 300 path(s), but there is no guarantee that resources along the new path 301 will be available. In addition, there is at least 1 RTT of delay and 302 the delta in initiating a new PATH message that delays reservation 303 establishment. 305 Some user groups, such as those found in the military, make a 306 distinction between mobile and transportable environments. The former 307 case resembles scenarios attributed to Mobile IP. The latter case is 308 characterized by wireless hosts operating in a new location, but never 309 moving to the extent that new paths through a network need to be 310 established. In this latter example, the challenges of RSVP in a 311 wireless environment are diminished. In addition, these environments 312 tend to involve a single administrative control of both hosts and 313 routing/forwarding nodes within a network infrastructure. 315 RSVP is associated with a means of retaining a minimal bound of 316 forwarding characteristics per flow, or aggregate of flows. As such, it 317 can be considered to run contrary to the objectives of ECN. However, in 318 cases where some flows must be reserved, CE feedback could be used to 319 signal the need to lower a pre-existing killer app reservation. 321 5.1.2 Differentiated Services 323 Unlike RSVP and its use of a separate signaling mechanism to reserve 324 resources, Differentiated Services (diff-serv) uses code points within 325 the IP header to convey the forwarding behavior of that packet 326 [rfc2474]. This may range from various drop precedence values to a code 327 point that signifies low delay and low loss (i.e., characteristics 328 attributed to real time flows). 330 As in the case of RSVP, applications could rely on the reception of CE 331 feedback to initiate a subsequent setting of diff-serv code points to 332 provide additional protection or explicit association of forwarding 333 characteristics of a given flow of packets. In addition, the setting of 334 diff-serv code points would be done on an as-needed basis in reaction to 335 CE feedback. Recommendations concerning specific diff-serv values are 336 outside the scope of this document. 338 5.1.2.1 Issues 340 Given the ease by which applications or middle boxes can set diff-serv 341 code points, the issue of trusting values other than best effort can 342 become problematic when hosts and routing/forwarding nodes are not 343 associated with a single administrative authority. 345 As in the case of RSVP, the effectiveness of diff-serv is dependent on 346 the number of nodes along a path that support the protocol. Thus, as 347 opposed to a single end-point reaction to CE feedback, differentiated 348 services requires additional support in the network to either increase 349 or decrease the probability of traffic being forwarded to its 350 destination. 352 A symbiotic capability to consider is the use of on-demand/as-needed 353 diff-serv code points to trigger downstream actions by the network. A 354 specific example would be a diff-serv code point sent in reaction to CE 355 feedback that could trigger alternate path routing via MPLS. 357 5.2 Fault Tolerance 359 Fault tolerance is another category of reactions that may be used by 360 applications in response to CE feedback. In some cases, these efforts 361 may contribute to an increase in traffic load in order to add protection 362 and resiliency to a flow. 364 Redundant Transmissions: This approach is based on a source sending 365 duplicate payloads that can be used to compensate for lost packets. Its 366 positive value may emerge in cases where a path has several downstream 367 congestion points that increase the probability that a packet will be 368 dropped instead of marked as CE and forwarded downstream. 370 Application Layer Forward Error Correction (FEC): This approach also 371 adds additional overhead to the flow in order to compensate for 372 potential packet loss. And as the case of redundant transmissions, the 373 value of this approach can be realized when there exists multiple 374 downstream congestion points that increase the probability of dropping 375 packets. However, the impact of the overhead is minimized by having one 376 (or a few) additional packet(s) used to compensate for the loss of a set 377 of packets. 379 Codec Swapping: This approach involves changing codecs to either reduce 380 load or achieve an improvement in compensating for lost packets. 381 Depending on the codec, the reduction of load may be a simple step 382 function, or it may involve a gradual and variable reduction in load 383 based on the rate of congestion feedback received by the source. 385 Interweaving packets: To Be Done (based on research at UCL) 387 5.2.1 Issues 389 The use of redundant transmissions or FEC produces a detrimental impact 390 of contributing to an increase in load and the measure of congestion 391 that triggers CE feedback. In the case of FEC, additional delay is 392 typically incurred through the generation of X amount of erasure packets 393 for each set of original source packets. And while an initial increase 394 in QoS may be observed for these flows, the overall rate of congestion 395 can be expected to increase. 397 Swapping codecs based on the reception of CE feedback has the positive 398 affect of reducing load at the risk of reducing perceived QoS by the 399 user. As in the case of all options described above regarding fault 400 tolerance, the ability to change to a different codec is depending on 401 end-to-end peer support. In addition, there is no assurance that the 402 different codec reduces load in relation to the amount of congestion 403 experienced over time. 405 5.3 Alternative Reaction for Emergency Communications 407 As mentioned in [rfc6679], the default reaction on the reception of these 408 ECN-CE marked packets MUST be to provide the congestion control algorithm with 409 a congestion notification that triggers the algorithm to react as if packet 410 loss had occurred. There MAY be an alternative reaction if it is considered 411 safe for deployment. An example of the need for an alternative reaction would 412 be the case of Emergency Telecommunications Service (ETS) [rfc3689, rfc4190], 413 where an improvement in QoS or a higher probability of session establishment 414 and forwarding of traffic is of high interest. 416 It is proposed that certain authorized ETS flows may be permitted to employ 417 either a substantially less aggressive back-off algorithm than the default 418 algorithm, or some level of exemption from reacting to ECN marked packets. 419 This alternative reaction will benefit these flows as the marks would normally 420 be considered as equivalent to lost packets, which would effectively increase 421 the loss level, which in turn will generally result in the reduction of flow 422 rate. This applies to all flows that utilize some form of the rate control that 423 is inversely proportional to the loss rate, which includes TCP-like algorithms 424 or equation-based approaches. 426 Simulations of the use of ECN exemption with TFRC and have found that it has 427 limited effect on the normal flows with low numbers of exempt flows. A 428 half-dumbbell network was used with a RED router queue configured using the 429 settings recommended by Sally Floyd. The candidate flows are 1Mbit/s each with 430 a backhaul 100Mbit/s link. In the standard case where 1% of flows would be 431 exempt the remaining flows achieve 99.99% of the bandwidth that they would 432 achieve without the presence of the exempt flows. This is what would be 433 expected from the simple calculation of the allocation, given that the exempt 434 flows achieve their full rate (1Mbit/s); With 100 normal plus 1 exempt flow, 435 assuming that the except flow uses 1Mbit/s, the remaining capacity is 99Mbit/s 436 which is divided between the 100 normal flows. Whilst when 101 normal flows 437 are run over the 100Mbit/s link they would have to share it evenly, so it works 438 out thus: ((99/100)/(100/101))*100=99.99%. In the case of 5% exempt flows then 439 the proportion is very slightly lower at ((95/100)/(100/105))*100=99.75%. Both 440 these calculations are borne out in the simulation runs. 442 The level of exemption employed can be altered in a number of ways. Two simple 443 approaches would be to either set a threshold number of ECN marked packets that 444 could be considered as a loss, and another approach would be to set a 445 percentage threshold of ECN marked packet that would be considered as a loss. 447 It should be noted that in the simulations the end-to-end delay of the packets 448 within the flows was monitored and the relative delay of the exempt flows 449 apparently rises somewhat when exemption is enacted. However what is actually 450 occurring is that the 'normal' flows are reducing their throughput and are thus 451 reducing their latency somewhat. There is normally some limited latency when 452 using loss-based techniques such as TFRC because it fills the queues to 453 ascertain the link capacity and maintains that level of delay throughout a 454 session. However the level of latency is clearly limited by the queue sizes in 455 the network and on media specific links these queue sizes are typically quite 456 small, so the resulting latency is limited. 458 Furthermore in the case where media flows employing TFRC, or any other 459 congestion control algorithm (e.g. delay-based), are sharing a bottleneck 460 link with TCP flows then the queues will be filled by the TCP flows and 461 the latency will be kept near or at a their maximum despite any other flows. 463 5.3.1 Issues 465 To Be Done 467 6. IANA Considerations 469 This document requires no actions from IANA. 471 7. Security Considerations 473 The reliance on accurate and un-modified RTCP information means that 474 SRTP needs to be used, or any other mechanism that helps prevent 475 modification of RTCP feedback packets. 477 8. Acknowledgements 479 TBD 481 9. References 483 9.1 Normative 485 [rfc2119] Bradner, S., "Key words for use in RFCs to Indicate 486 Requirement Levels", BCP 14, RFC 2119, March 1997. 488 [rfc2205] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP) 489 Version 1 Functional Specification", RFC 2205, September 490 1997 492 [rfc2209] Braden, R., L. Zhang, "Resource Reservation Protocol 493 (RSVP) Version 1 Message Processing Rules", RFC2209 494 September 1997 496 [rfc2474] Nichols, K., et. al., "Definition of the Differentiated 497 Services Field in the IPv4 and IPv6 Headers", RFC 2474, 498 December 1998 500 [rfc3168] Ramakrishnan, K,. et. al., "The Addition of Explicit 501 Congestion Notification (ECN) to IP", RFC 3168, 502 September, 2001 504 [rfc3181] Herzog, S., "Signaled Preemption Priority Policy Element", 505 RFC 3181, October 2001 507 [rfc3448] Handley, M., et. al., "TCP Friendly Rate Control (TFRC): 508 Protocol Specification", RFC 3448, January 2003 510 [rfc3583] Chaskar, H., "Requirements of a Quality of Service (QoS) 511 Solution for Mobile IP", RFC 3583, September 2003 513 [rfc4867] Sjoberg, J., et. al., "RTP Payload Format and File Storage 514 Format for the AMR and AMR-WB Audio Codecs", RFC 4867, 515 April 2007 517 [rfc5104] Wenger, S., et. al., "Codec Control Messages in the RTP 518 Audio-Visual Profile with Feedback (AVPF)", RFC 5104, 519 February 2008 521 [rfc6679] Westerlund, M., et. al., "Explicit Congestion Notification 522 (ECN) for RTP over UDP", RFC 6679, IETF, Aug 2012 524 9.2 Informative 526 [draft-rtp-tfrc] Gharai, L., C. Perkins, "RTP with TCP Friendly Rate 527 Control", work-in-progress, Sept 2011 529 [draft-tcpm-accecn-reqs] M. Kuehlewind, R. Scheffenegger, "Problem 530 Statement and Requirements for a More Accurate ECN Feedback", 531 work-in-progress, Feb 2013 533 [Goog1] http://code.google.com/apis/talk/call_signaling.html 535 [tr26.114] "IMS; Multimedia telephony; Media Handling and 536 Interaction", 3GPP, version 10, April 2011 538 [ts36.300] "E-UTRA and E-UTRAN Overall Description, Stage 2", 539 3GPP, Release 10, September, 2011 541 [rfc4340] Kohler, E., et. al, Datagram Congestion Control 542 Protocol (DCCP), RFC4340, March 2006 544 [rfc4342] Floyd, S., et. al., "Profile for DCCP Congestion 545 Control ID 3: TFRC", RFC 4342, March 2006 547 [rfc4828] Floyd, S., E. Kohler, "TFRC: The Small Packet 548 Variant", RFC 4828, April 2007 550 [rfc3689] Carlberg, K., Atkinson, R., "General Requirements for 551 Emergency Telecommunications Service (ETS)", RFC 3689, 552 February 2004 554 [rfc4190] Carlberg, K. et, al., "Framework for Supporting 555 Emergency Telecommunications Service (ETS) in 556 IP Telephony", RFC 4190, November 2005 558 [rfc3714] Floyd, S., Kempf, J., "IAB Concerns Regarding Congestion 559 Control for Voice Traffic in the Internet", RFC 3714, 560 March 2004 562 [bcp145] Eggert, L., Fairhurst, G., "Unicast UDP Usage Guidelines 563 for Application Designers", RFC 5405, BCP 145, November 2008 565 [ITU.G114.2003] 566 International Telecommunications Union, "One-way 567 transmission time", ITU-T Recommendation G.707, May 2003. 569 Author's Addresses 571 Piers O'Hanlon 572 University of Oxford 573 Oxford Internet Institute 574 1 St Giles 575 Oxford OX1 3JS 576 United Kingdom 578 Email: piers.ohanlon@oii.ox.ac.uk 580 Ken Carlberg 581 G11 582 1600 Clarendon Blvd 583 Arlington VA 584 USA 586 Email: carlberg@g11.org.uk