idnits 2.17.1 draft-iab-cc-workshop-report-00.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 date (January 30, 2013) is 4097 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '41' is defined on line 933, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5405 (ref. '2') (Obsoleted by RFC 8085) == Outdated reference: A later version (-18) exists of draft-ietf-avtcore-rtp-circuit-breakers-01 == Outdated reference: A later version (-08) exists of draft-ietf-tcpm-initcwnd-07 -- Obsolete informational reference (is this intentional?): RFC 2309 (ref. '24') (Obsoleted by RFC 7567) == Outdated reference: A later version (-02) exists of draft-nichols-tsvwg-codel-00 -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '34') (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 5245 (ref. '35') (Obsoleted by RFC 8445, RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 6347 (ref. '36') (Obsoleted by RFC 9147) == Outdated reference: A later version (-17) exists of draft-ietf-httpbis-http2-01 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Tschofenig 3 Internet-Draft L. Eggert 4 Intended status: Informational Z. Sarker 5 Expires: August 3, 2013 January 30, 2013 7 Report from the IAB/IRTF Workshop on Congestion Control for Interactive 8 Real-Time Communication 9 draft-iab-cc-workshop-report-00.txt 11 Abstract 13 This document provides a summary of the IAB/IRTF Workshop on 14 'Congestion Control for Interactive Real-Time Communication', which 15 took place in Vancouver, Canada, on July 28, 2012. The main goal of 16 the workshop was to foster a discussion on congestion control 17 mechanisms for interactive real-time communication. This report 18 summarizes the discussions and lists recommendations to the Internet 19 Engineering Task Force (IETF) community. 21 The views and positions in this report are those of the workshop 22 participants and do not necessarily reflect the views and positions 23 of the authors, the Internet Architecture Board (IAB) or the Internet 24 Research Task Force (IRTF). 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on August 3, 2013. 43 Copyright Notice 45 Copyright (c) 2013 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Workshop Structure . . . . . . . . . . . . . . . . . . . . . . 5 62 2.1. History and Challenges . . . . . . . . . . . . . . . . . . 5 63 2.2. Simulations and Measurements . . . . . . . . . . . . . . . 8 64 2.3. Challenges and Design Properties . . . . . . . . . . . . . 9 65 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 14 66 3.1. Changes to Network Infrastructure . . . . . . . . . . . . 14 67 3.2. Avoiding Self-Inflicted Queuing . . . . . . . . . . . . . 15 68 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 72 7.1. Normative References . . . . . . . . . . . . . . . . . . . 21 73 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 74 Appendix A. Program Committee . . . . . . . . . . . . . . . . . . 25 75 Appendix B. Workshop Material . . . . . . . . . . . . . . . . . . 26 76 Appendix C. Accepted Position Papers . . . . . . . . . . . . . . 27 77 Appendix D. Workshop Participants . . . . . . . . . . . . . . . . 30 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 80 1. Introduction 82 Any application that sends significant amounts of data over the 83 Internet is expected to implement reasonable congestion control 84 behavior. The goals for congestion control are well understood and 85 documented in RFC 2914 [1] and RFC 5405 [2]: 87 1. Preventing congestion collapse. 89 2. Allowing multiple flows to share the network fairly. 91 The Internet has been used for interactive real-time communication 92 for decades, most of which is being transmitted using RTP over UDP, 93 often over provisioned capacity and/or using only rudimentary 94 congestion control mechanisms. 96 The development and upcoming widespread deployment of web-based real- 97 time media communication - where RTP is used to and from web browsers 98 to transmit audio, video and data - will likely result in substantial 99 new Internet traffic. Due to the projected volume of this traffic, 100 as well as the fact that it is more likely to use unprovisioned 101 capacity, it is essential that it is transmitted with robust and 102 effective congestion control mechanisms. 104 Designing congestion control mechanisms that perform well under a 105 wide variety of traffic mixes and over network paths with widely 106 varying characteristics is not easy. Prevention of congestion 107 collapse can be achieved through a "circuit breaker" mechanism (see, 108 for example, [3]), but for media flows that are supposed to coexist 109 with a user's other ongoing communication sessions, a congestion 110 control mechanism that shares capacity fairly in the presence of a 111 mix of TCP, UDP and other protocol flows is needed. 113 Many additional complications arise. Here are some examples: 115 1. Real-time interactive media sessions require low latencies, 116 whereas streaming media can use large play-out buffers. 118 2. In an Real-time Transport Protocol (RTP) session feedback 119 exchanged via the RTP Control Protocol (RTCP) typically arrives 120 much less frequently than, for example, TCP ACKs for a given TCP 121 connection. Theoretically, the RTP/RTCP control loop can lead to 122 a longer reaction time. 124 3. Media codecs can usually only adjust their output rates in a much 125 more coarse-grained fashion than, for example, TCP, and user 126 experience suffers if encoding rates are switched too frequently. 127 Codecs typically have a minimum sending rate as well. 129 4. Some bits of an encoded media stream are more important than 130 others. For example, losing or dropping an I-frame of a video 131 stream is more problematic than dropping a P-frame [4]. 133 5. Ramping up the transmission rate can be problematic. Simply 134 increasing the output rate of the codec without knowing whether 135 the network path can sustain transmission at the increased rate 136 runs the danger of incurring a significant amount of packet loss 137 that can cause playback artifacts. 139 6. A congestion control scheme for interactive media needs to handle 140 bundles of interrelated flows (audio, video, data), in a way that 141 accommodates the preferences of the application in the event of 142 congestion. 144 7. The desire to provide a congestion control mechanism that can be 145 efficiently implemented inside an application (e.g., a web server 146 and a browser) imposes additional restrictions. 148 8. There are explicit congestion signals (such as Explicit 149 Congestion Notification (ECN) [5]), and there are implicit 150 indications of congestion (e.g., packet delay and loss). Care 151 must be taken to account for each of these signals, particularly 152 if various applications react on the same set of signals. 154 9. Large buffers are often used in network elements and end device 155 operating systems to better support TCP-based applications. 156 These buffers introduce additional communication delay, which 157 harms the small delay budget available for interactive real-time 158 applications. 160 The Internet Architecture Board (IAB) raised concerns regarding 161 possibilities of a congestion collapse due to a rapid growth in real- 162 time voice traffic that does not practice end-to-end congestion 163 control in early 2004 [6]. This congestion collapse did not happen 164 but the raised concerns are still valid and have gained more 165 relevance when applied to more bandwidth-hungry video applications. 166 Congestion collapse is, however, not the only concern as discussed in 167 this workshop report. 169 2. Workshop Structure 171 The IETF has a long history in the work on congestion control 172 mechanisms but with the ongoing standardization work on real-time 173 interactive media communication on the Web new challenges emerged and 174 existing work got revisited. To take a deeper look at the topic the 175 participants contributed 32 papers as input to the one-day workshop. 177 The workshop started with a keynote speech of Mark Handley describing 178 the history of the work on congestion control for real-time media 179 followed with his views of the problems. A summary of the 180 discussions and the identified issues are captured in the subsections 181 below. 183 2.1. History and Challenges 185 The primary goal of congestion control is to avoid congestion 186 collapse - to make the network work. The second important goal is to 187 guarantee some sort of fairness so that all users get some service. 188 Section 3 of RFC 2914 [1] discusses these two goals in detail and 189 references earlier work, such as [7]. [7] informs about historic 190 incidents, such as congestion collapse due to unnecessarily- 191 retransmitted, undelivered, and fragmented packets. 193 Mark Handley argues that since 1988, the Internet has remained 194 functional despite exponential growth, routers that are sometimes 195 buggy or misconfigured, rapidly changing applications and usage 196 patterns, and flash crowds. This is largely because most 197 applications use TCP, and TCP implements end-to-end congestion 198 control. 200 TCP's congestion control adapts the window to fit the capacity 201 available in the network and accomplishes approximate fairness 202 between two competing flows over a period of time. Mark indicates 203 that the provided level of fairness is not necessarily what we want: 204 The 1/round-trip-time relationship in TCP is not wonderful since it 205 means that network operators can decide to lower packet loss by 206 adding bigger buffers (which unfortunately leads to bufferbloat 207 problems). The 1/sqrt(packet drop rate) relationship is also not 208 necessarily desirable since TCP did not work particularly well for 209 high-speed flows (which had been subject for a lot of TCP research). 211 TCP controls the congestion window in bytes. For bulk transfer, 212 usually this results in controlling the number of 1500 byte packets 213 per second sent. Real-time media is, however, different since it has 214 its own time constraints. For audio we want to send one packet per 215 20ms and for video the ideal value would be 25 to 30 frames per 216 second. We therefore want to avoid additional sending delay. 218 As an example, in case of video, to relieve congestion one has to 219 reduce the number of packets-per-second transmission rate rather than 220 transmitting smaller packets since at higher bitrates on WiFi the 221 time it takes to send a packet is almost negligible compared to the 222 time that is spent with MAC layer operations. Reducing the packet 223 size makes little difference to the available capacity. For a serial 224 line it does not matter how big the packets are. 226 From a network point of view the goals of congestion control 227 therefore are: 229 1. Avoid congestion collapse 231 2. Avoid starvation of TCP flows 233 3. Avoid starvation of real-time flows. Specifically, in the case 234 where TCP and real-time flows share the same FIFO queue. 236 From an application point of view the goals of congestion control are 237 different, namely: 239 1. Robust behavior. One wants to have a good throughput when the 240 network is working well and it still works when the network is 241 working poorly. 243 2. Predictable behavior. This matters from a usability point of 244 view since variable media quality is bad for users. 246 3. Low latency. With large buffers along the end-to-end path the 247 latency will increase when interactive real-time flows compete 248 with TCP flows since TCP will fill up the buffers and the 249 increased buffering leads to additional delays for the delivery 250 of the interactive real-time media. 252 Attempts for providing congestion control for interactive real-time 253 media were already done much earlier in the IETF, for example, with 254 the work on TCP-Friendly Rate Control (TFRC) [8]. It illustrates the 255 challenges quite well. TFRC tries to accomplish the same throughput 256 as TCP, but with smoother transmission rate. It measures the loss 257 and the round-trip time but follows a similar model as TCP to 258 determine the sending rate. 260 In a link with low statistical multiplexing TCP can lead to bad 261 oscillations. The sending rate hits the maximum rate of a bottleneck 262 link, a lot of loss occurs, and then the sending rate peaks again. 263 For very small buffers the result is acceptable but bigger buffers 264 lead to oscillations. The result is bad for networks and for 265 applications. To deal with large buffers on these links a short-term 266 rate adaptation based on round-trip time (RTT) information is 267 utilized in TRFC but this requires good short-term RTT measurements. 269 TRFC works pretty well in theory. TFRC assumes the network is in 270 charge of the codec and that the codec can produce data at the 271 demanded rate. Modern video codecs inherently produce variable- 272 bitrate video streams based on the content being encoded, and it is 273 hard to produce data at exactly the desired bitrate without excessive 274 buffering or ugly quality changes. 276 What if we put the codec in charge instead of the network? The 277 network tells the codec the mean rate but it does not worry about 278 what happens in short time scales and the codec matches the mean rate 279 and does not worry whether it is over or under the rate for a 280 relatively short time scale. This again leads to the low statistical 281 multiplexing problem and leads to oscillations. 283 Known congestion control mechanisms work well if they can respond 284 quickly enough to changes if they do not bump into the low 285 statistical multiplexing problem. 287 To avoid the low statistical multiplexing problem techniques for 288 inferring linkspeed are needed and the work from Van Jacobson's 289 pathchar [9] (and successors) serve as valuable input. The idea is 290 to send short packet trains, to measure timing accurately, and to 291 infer the linkspeed from the relative delay. If we know the 292 linkspeed, we can avoid exceeding it. Congestion control can give us 293 an approximate rate, but we must not exceed linkspeed. This is a 294 hybrid between codec being in charge (most of the time), and network 295 being in charge. These work well for some links, but not for others. 296 Wireless links where speed can change in less than a single RTT 297 because of fading, bitrate adaption, etc. cause problems. We would 298 like to have the codec and the network to be in charge. However, 299 they cannot be both in charge at the same time. 301 Mark indicated that he is not entirely sure whether RTCP is suitable 302 for congestion control. "RTCP gives feedback, but it cannot send it 303 often enough to avoid bumping into linkspeed." he says. Circuit 304 breakers [3] on the other hand do not help to give good performance 305 on an uncongested path. With circuit breakers the sender measures 306 the loss rate and RTT, and runs with a loose "cap". 308 As a conclusion, Mark Handley claims that we know how to do good 309 congestion control, but only if congestion control is in charge, and 310 that's not acceptable for real-time applications. We only know how 311 to do good congestion control if we change packet/sec rate and not 312 packet size. 314 2.2. Simulations and Measurements 316 This second part of the workshop was focused on the presentation and 317 the discussion of data gathered from simulations and real-world 318 measurements. 320 Keith Winstein started the discussion with his presentation of 321 measurements performed in cellular operator networks in the US [10]. 322 The measurements indicate that the analyzed cellular networks showed 323 varying RTT with transient latency spikes to hundreds of ms, link 324 speed that varies by a factor of 10 in a short time scale, and 325 buffers that do not drop packets until they contain 5 - 10 seconds of 326 data at bottleneck link speed. 328 Zaheduzzaman Sarker [11] presented results from real-time video 329 communication in an LTE simulator utilizing ECN-based packet marking 330 and adaptation using implicit methods like packet loss and delay. 331 ECN marking provides ways for the network to explicitly signal 332 congestion hence distributes the cost of congestion well and helps 333 achieving lower latency. However, although RFC 3168 [5] was 334 finalized in 2001 the deployment of ECN is still lacking as 335 investigated by Bauer, et al. [12]. A few participants noted that 336 they believe that the deployment of LTE networks will also increase 337 the deployment of ECN. 339 Mo Zahaty [13] discussed TFRC [8] and TFRC with weighted fairness 340 (MulTFRC) [14], which tunes TFRC to consider multiple flows, and 341 showed the impact of RTT and loss rates on the type of video quality 342 that can be achieved under those conditions. TFRC requires frequent 343 feedback, which RTCP does not provide even when considering the 344 extended RTP profile for RTCP-based feedback (RFC 4585 [15]). Mo 345 argued that application-specified weighted fairness is important but 346 while MulTFRC provides better performance than TFRC it is not clear 347 whether the added complexity over an n-times-TFRC approach is indeed 348 worth the effort. 350 Markku Kojo shared analysis results of how real-time audio is 351 affected by competing TCP flows. In the experiments shown in Figure 352 2 of [16] a real-time interactive audio stream had to compete against 353 one TCP flow, and, as a comparison, against six TCP flows. With one 354 concurrent TCP flow voice is impacted on startup and six TCP flows 355 destroy quality of call. Two types of losses were analyzed, namely 356 losses that result from a packet being dropped in the network (e.g., 357 due to congestion or link errors) and losses that result from the 358 delayed arrival of the packet (due to buffering) when the audio 359 packet misses the deadline for the codec to decode and play the 360 transmitted content. Consequently, even a moderate number of TCP 361 flows typically used by browsers to retrieve content on Web pages in 362 parallel causes irreparable harm for audio transfers. The size of 363 the initial window also impacts interactive real-time communication 364 since a larger TCP initial window size (e.g., IW(10) with ten 365 segments, as proposed in [17], instead of three) leads to a bigger 366 burst of packets because of the initial window transmission. Note 367 that the study in [18] does not necessarily lead to the same 368 conclusion. It claims that that the increased initial window size 369 leads to no impact or only modest impact for buffering in the 370 majority of cases. 372 Cullen Jennings [19] presented measurement results showing 373 interactions between RTP and TCP flows for several widely deployed 374 video communication products, i.e., Apple Facetime, Google Hangout, 375 Cisco Movi, and Microsoft Skype. While all tested products 376 implemented some form of congestion control none of the applications 377 did additive increase and multiplicative decrease (AIMD). In 378 general, it was observable that video adapts more slowly than AIMD to 379 changes in available bandwidth, because most codecs cannot make small 380 increases in sending rates when available bandwidth increases, and do 381 not make large decreases in sending rates when available bandwidth 382 decreases, in order to improve the user's experience. 384 Stefan Holmer [20] investigated the difference between loss-based and 385 delay-based congestion control algorithms. The suitability of loss- 386 based congestion control schemes for interactive real-time 387 communication systems heavily depends on buffer sizes and the 388 deployment of active queue management mechanisms. If most routers 389 are using tail-drop queuing, then loss-based congestion control 390 cannot fulfill the requirements of interactive real-time applications 391 since those flows will effectively increase the bitrate until a loss 392 event is identified, which only happens when the bottleneck queue is 393 full. 395 2.3. Challenges and Design Properties 397 During the remaining part of the workshop the participants discussed 398 challenges and identified design properties. The discussions in this 399 session started with a presentation by Jim Gettys about problems 400 related to bufferbloat [21][22]. Bufferbloat is "a phenomenon in a 401 packet-switched computer network whereby excess buffering of packets 402 inside the network causes high latency and jitter, as well as 403 reducing the overall network throughput." [23]. A certain amount of 404 buffering is helpful to improve the efficiency. Not dropping packets 405 in the event of congestion leads to increasing delays for interactive 406 real-time communication. 408 Packets may get buffered at various places along the end-to-end path 409 including in the operating system/device drivers, customer premise 410 equipment (such as cable modem and DSL routers), base stations, and 411 routers. While the understanding of too large buffers has improved 412 over the last few years the participants were still concerned that 413 many equipment manufactures and network operators do not yet 414 acknowledge the existence of the problem. This lack of understanding 415 is caused by the strong focus on throughput network performance 416 measurements that do not take latency into account. For example, 417 only recently the Federal Communications Commission (FCC) has added 418 latency tests to their test suites [REF missing]. 420 Active queue management (AQM) aims to prevent queues from growing too 421 large. This is accomplished by the monitoring queue length and by 422 informing the sender by dropping or marking packets to lower their 423 transmission rate. Random Early Detection (RED) [24] is one such AQM 424 algorithm but it has not been widely deployed in routers largely 425 because of challenges to configure it correctly [25]. According to 426 [26], RED does not work with the default settings as it is "too 427 gentle to handle fast changes due to TCP slow start when the 428 aggregate traffic is limited". There may also be a lack of 429 incentives to deploy AQM algorithms. Participants speculated about 430 the time it takes to update network equipment (to support AQM 431 algorithms) considering the different replacement cycles of these 432 devices. Measurement tools that allow an end user to determine the 433 performance of their network, including latency, is seen as a 434 promising approach to motivate network operators to upgrade their 435 equipment and to make use of AQM algorithms. Measurement tools would 436 allow users to determine how bad your network performs and to 437 complain to your ISP and thereby creating a market force. As to what 438 the right performance measurement metrics are it was noted that the 439 intent of the IETF IP Performance Metrics (IPPM) working group [27] 440 was to develop such metrics to qualify networks it may have started 441 too early. There are, however, recent attempts to re-visit the 442 measurement work and an effort by the FCC has gotten a lot of 443 attention recently, see [28]. 445 Matt Mathis argued that the traffic of throughput-maximizing and 446 delay-minimizing applications need to be in separate queues, i.e. 447 that segregated queuing is applied. Requiring segregated queues 448 assumes you are sharing the network with other greedy traffic. 449 Others agreed with him. Quality of Service signaling is a way to 450 deploy segregated queuing but there are several simpler alternatives, 451 such as Stochastic Fair Queuing [29]. The Controlled Delay (CoDel) 452 AQM algorithm [30] can also be used in combination with stochastic 453 fair queuing. Note that queue segregation is not necessary for every 454 router to segregate and using it at the edge of a network where 455 bottleneck links are is already sufficient. 457 It was noted that current interactive voice usage over the Internet 458 works most of the time satisfactory. In typical networks, the reason 459 voice works is because networks are underloaded. As long as there is 460 idle capacity and the queue is empty when your packets arrive, 461 traffic does not be separated into distinct queues. Further 462 explanations were offered why many networks work surprisingly well: 463 LEDBAT [31] is used for the download of software updates, voice 464 traffic contributes only a small percentage of the overall Internet 465 traffic, and "human protocols" (e.g., parents asking their kids to 466 get off the network during the time of a conference call). 468 Cullen Jennings raised a concern that not providing a solid 469 congestion control mechanism for interactive video, as it was done 470 with interactive voice, could have substantial impact due to the 471 potential uptake in deployment triggered by the work on RTCWeb. He 472 phrased it as "I'm worried about the approach that says 'Let us do 473 the minimal' and that is what we did with voice -- nothing. If we do 474 the same with video, we're going to be in trouble. In the class of 475 space where voice is currently working, that's where I'm worried 476 about video failing." Ted Hardie countered by saying that RTCWeb is 477 trying to replace existing proprietary technologies. It may ramp up 478 the amount of use we are expecting, but it is not doing much that was 479 not being done by Adobe Flash or Skype. RTCWeb is not a totally 480 novel context of Internet usage. Magnus Westerlund concluded that 481 RTCWeb might be driver for the moment, but we are not only talking 482 about Web browsers. 484 Furthermore, Ted noted that applications will not produce media 485 streams that grow to 10Mbps because their sending rate is auto-rate- 486 limited by the production of the video. He suggested to ask 487 ourselves if we are trying to get TCP to be friendly to media 488 streams, which are already rate-limited or are we asking media 489 streams that are already rate-limited to be TCP friendly? He then 490 quoted Andrew McGregor: "It's really not good to be TCP-friendly 491 because it's not going to return the favor." If the desired 492 properties we want are no starvation, fairness, and effective goodput 493 for the offered loads, is the only thing we're willing to consider 494 changes in RTP control or are we willing to consider changes in TCP 495 congestion control? 497 This led to a discussion whether the development of a congestion 498 control algorithm for interactive real-time applications provides any 499 value if network equipment suffers from bufferbloat. Is there 500 something that can be done today to help interactive real-time media 501 or do we have to wait to get the network updated first? Replacing 502 home routers and updating routers with modern AQM algorithms was seen 503 as a longer-term effort. Also, the time scale for changing TCP's 504 congestion control is on the time scale as deploying ECN [5]. Colin 505 Perkins noted that while we cannot change TCP quickly, but the way 506 TCP is being used is changing quickly and we can impact the way TCP 507 is used. When TCP is used for file transfer it will send data as 508 fast as it can but when TCP is used for WebSockets, the dynamics are 509 different. WebSockets and SPDY are clearly changing the behavior of 510 TCP. Also, Netflix-style video streaming applications are huge users 511 of TCP and those applications can change rather quickly. Matt Mathis 512 added that real-time videoconferencing almost always produces video 513 streams at a lower bitrate than downloading equivalent-sized stored 514 video using best-effort file-sharing will produce. 516 Bill Ver Steeg suggested to consider three different deployment 517 environments, namely 519 1. Flows competing with flows from the host ("self-inflicted queuing 520 delay") 522 2. Flows competing with flows in the same sub-network (e.g. home 523 network) 525 3. Flows competing with flows from other networks (e.g., traffic 526 from different households that utilize the same DSL provider) 528 The narrowest problem domain that makes sense is to avoid self- 529 inflicted queuing delay. Michael Welzl indicated that this requires 530 an information exchange (called flow-state exchange) inside a browser 531 (at the level of the same host or even beyond, as described in [32]) 532 to synchronize congestion control of different audio, video, and data 533 flows. Although it would provide great benefits if one could share 534 information about a bottleneck with all the flows sharing that 535 bottleneck but this is considered challenging even within a single 536 host. John Leslie [33] also noted: "We're acting as if we believe 537 congestion will magically be solved by a new transport algorithm. It 538 won't." Instead, an interaction between the network layer, transport 539 layer, and the application layer is needed whereby the application 540 layer is the only practical place to balance what piece(s) to 541 constrain to lower bandwidths. All flows relating to a user session 542 should have a common congestion controller. For many applications, 543 audio is much more critical than video. In those cases the video may 544 back off, but the audio transmission remains unchanged. 546 Mo Zanaty pointed to the importance of the media start-up behavior, 547 which is an area where the exchange of real-time interactive media is 548 different from a TCP-based file transfer. The instantaneous 549 experience in the first part of a video call is highly determinative 550 of people's perception of the call quality. Vendors are using vague 551 heuristics, for example, data from the last call to figure out what 552 to do on the next call. Lars Eggert highlighted that the start-up 553 behavior of an application affects ongoing performance of other flows 554 if, for example, an application blast at line rate at the beginning 555 of a video stream. You need to start slow enough to not cause 556 congestion to others. Randell Jesup argued that for an interactive 557 real-time video application, you really need to have most of your 558 bandwidth right away. Colin Perkins agreed and added that on startup 559 you need good quality video quickly, but how quickly? For a phone 560 call one needs to be able to say "Hello!" pretty quickly, but for 561 video it may not be necessary to see the other person very quickly. 562 Those requirements are likely going to be different from audio to 563 video and maybe even vary between different applications. Various 564 protocol exchanges take place before media is exchanged between 565 endpoints (such as STUN packets [34] as part of the ICE [35] or a 566 DTLS security handshake [36]) and may be used to the advantage to 567 obtain a couple simple measurements. 569 The group agreed that it is feasible to design a congestion control 570 algorithm that work on mostly idle networks. In the view of the 571 participants upgrades of the network infrastructure can happen in 572 parallel. This view was later confirmed at the RTP Media Congestion 573 Avoidance Techniques (RMCAT) Birds of a Feather ("BoF") meeting at 574 IETF#84 (July 29 - August 3, 2012, Vancouver, BC, Canada) that led to 575 the formation of the RMCAT working group [37]. 577 3. Recommendations 579 The participants suggested to explore two complementary solution 580 tracks, as described in the two sub-sections below. 582 3.1. Changes to Network Infrastructure 584 Like for all other traffic on the network, better data plane 585 infrastructure improves the perceived quality of the best-effort 586 service the Internet provides for RTCWeb flows. The IETF has already 587 developed several technologies that would be of immediate usefulness, 588 if they were deployed. The workshop participants expressed the hope 589 that due to the volume and importance of RTCWeb traffic, some of 590 these technologies might finally see widespread use. 592 The first and by far most important improvement is traffic 593 segregation, i.e., the ability to use different queues for different 594 traffic types. Specifically jitter/delay sensitive protocols would 595 benefit from being in different queues from throughput maximizing 596 protocols. It is not possible for a single queue/AQM to be optimal 597 for both. 599 Furthermore, ECN allows routers along the end-to-end path to signal 600 the onset of congestion and allows applications to respond early, 601 avoiding losses and keep queue sizes short and therefore end-to-end 602 delay low. ECN is implemented on some end system stacks and routers, 603 but frequently not enabled. The participants expressed the 604 importance to increase the deployment of ECN, even if used initially 605 only in closed environments likes data centers (as with Data Center 606 TCP (DCTCP) [38]. 608 Different mechanisms have been developed to facilitate traffic 609 segregation. Differentiated Services [39] are one possibility in 610 this space. If applications start to mark outgoing traffic 611 appropriately and routers would segregate traffic accordingly, 612 browsers could more directly control the relative importance of their 613 various flows, and avoid self-competition. Compared to ECN, however, 614 DiffServ is far more difficult to deploy meaningfully end-to-end, 615 especially given that DSCPs have no defined end-to-end meaning and 616 packets can be re-marked. Quality-of-service (QoS) signaling 617 together with resource reservation facilities would enable a fine- 618 grained and flexible way to indicate resource needs to network 619 elements but it is also by far the most heavyweight proposal, and 620 unlikely to be viable in the global Internet. However, as mentioned 621 in Section 2.3 QoS signaling is not the only way to accomplish 622 traffic segregation. Further investigations regarding stochastic 623 fair queuing and new AQM algorithms is seen as desirable. 625 In any case, network infrastructure updates will take time 626 particularly if the interest of the involved stakeholders is not 627 aligned (as is often the case for network operators). It is 628 therefore imperative that RTCWeb congestion control provides adequate 629 improvement in the absence of any of the aforementioned schemes. 631 3.2. Avoiding Self-Inflicted Queuing 633 This approach tries to ensure that the network does not suffer from 634 congestion collapse and that one data flow from a single host does 635 not harm another data stream from the same host. A single congestion 636 manager within the end host or the browser could already help to 637 coordinate various congestion control activities and to ensure a more 638 coordinated approach between different applications, and different 639 flows. 641 The following activities were suggested during the workshop. 643 Reacting to all Congestion Signals: 645 To initiate the congestion control process it is important to 646 detect congestion in the communication path. Congestion can be 647 detected using either an explicit mechanism or an implicit 648 mechanism. The explicit mechanism involves direct congestion 649 signaling usually from the congested network node, such as ECN. 650 In case of implicit mechanism, packet loss events or observed 651 delay increase is used as an indication for congestion. These 652 measurements can also be made available in a variety of different 653 protocols, such as RTCP reports or transport protocols. It is 654 recommended for applications to take all available congestion 655 signals into account and to couple the congestion control 656 algorithm, the codec and the application so that better 657 information exchange between these components is possible since 658 there are constraints on how quickly a codec can adapt to a 659 specific sending rate. 661 Delay- and Loss-based Algorithms: 663 The main goal of designing a congestion control algorithm for 664 real-time conversational media is to achieve low latency. 665 Although explicit congestion signals provide the most reliable way 666 for applications to react. However, due to the lack of ECN 667 deployment delay based algorithms are needed. Since there is 668 large delay variation in wireless networks (even in a non- 669 congested network) the workshop participants recommended that more 670 research should be done to better understand non-congestion 671 related delay variation in the network. General consensus among 672 the workshop participants was that latency-based congestion 673 control algorithms are needed due to the lack of loss indications 674 caused by large buffers but when latency-based techniques were 675 competing against loss-based techniques, the loss-based techniques 676 got all the bandwidth. 678 Algorithm Evaluation: 680 The Internet consists of heterogeneous networks, which also 681 includes misconfigured, and unmanaged network nodes. Bandwidth 682 and latency varies a lot. Not only this, different services 683 deployed using RTP/UDP have different requirements in terms of 684 media quality. A congestion control algorithm needs to perform 685 well not only in simulators but also in the deployed Internet. To 686 achieve this it is recommended to test the algorithms with real- 687 world loss and delay figures to ensure that the desired audio/ 688 video rates are attainable using the proposed algorithms for the 689 desired services. 691 Media Characteristics in Focus: 693 Interactive real-time voice and video data is inherently variable. 694 Usually the content of the media and service requirements dictate 695 the media coding. The codec may be bursty and not all frames are 696 equally important (e.g., I-frames are more important than 697 P-frames). Thus, codecs have limited room for adaptation. 698 Congestion control for audio and video codecs is therefore 699 different to congestion control applied to bulk transfers. The 700 latter are allows buffering of media irrespective to their content 701 and more fine-grained control for a congestion control algorithm. 702 In the workshop these limitations were brought up and the workshop 703 participants recommended that a congestion controller needs to be 704 aware of these constraints. However, further investigation is 705 needed to decide what information needs to be exchanged between a 706 codec and the congestion manager. 708 Startup Behaviour: 710 The startup media quality is very important for real-time 711 interactive application and for user-perceived application 712 performance. The startup behavior of these is also different to 713 other traffic. By nature the real-time interactive communication 714 applications want to provide a smooth user experience and maintain 715 best media quality to ease the interaction. While it may be 716 desirable from a user experience point of view to immediately 717 start streaming video with high-definition quality and audio of a 718 wideband codec this will have impacts on the bandwidth of the 719 already ongoing flows. As such, it would be ideal to start slow 720 enough to avoid excessive congestion to other flows but fast 721 enough to offer a good user experience. The sweetspot, however, 722 yet has to be found. 724 Some workshop participants also recommended to change the way TCP is 725 used in browsers and other HTTP-based applications. For example, by 726 not opening too many concurrent TCP connections, and by improving the 727 interaction with other non-real-time applications (such as video 728 streaming and file sharing) additional improvements can be made. The 729 work on HTTP 2.0 with SPDY [40] is already the step in the right 730 direction since SPDY makes use of a more aggressive form of 731 multiplexing instead of opening a larger number of TCP connections. 733 Finally, it was noted that ongoing IETF standardization activities 734 should be supported with deployment tests, not just simulations, to 735 verify the effectiveness of developed congestion control algorithms. 737 4. Acknowledgments 739 We would like to thank the participants and the paper authors of the 740 position papers for their input. 742 Additionally, we would like to thank the following persons for their 743 review comments: Michael Welzl, John Leslie, Mirja Kuehlewind, Matt 744 Mathis, Mary Barnes, Spencer Dawkins, Alissa Cooper 746 5. IANA Considerations 748 This memo includes no request to IANA. 750 6. Security Considerations 752 Two position papers focused on security but these papers were not 753 discussed during the workshop. As such, nothing beyond the material 754 contained in those position papers can be reported. 756 7. References 758 7.1. Normative References 760 [1] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, 761 September 2000. 763 [2] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for 764 Application Designers", BCP 145, RFC 5405, November 2008. 766 7.2. Informative References 768 [3] Perkins, C. and V. Singh, "RTP Congestion Control: Circuit 769 Breakers for Unicast Sessions", 770 draft-ietf-avtcore-rtp-circuit-breakers-01 (work in progress), 771 October 2012. 773 [4] Wikipedia, "Video compression picture types", URL: 774 http://en.wikipedia.org/wiki/Video_compression_picture_types, 775 Jan. 2012. 777 [5] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of 778 Explicit Congestion Notification (ECN) to IP", RFC 3168, 779 September 2001. 781 [6] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion 782 Control for Voice Traffic in the Internet", RFC 3714, 783 March 2004. 785 [7] Floyd, S. and K. Fall, "Promoting the Use of End-to-End 786 Congestion Control in the Internet", IEEE/ACM Transactions on 787 Networking, URL: http://www.aciri.org/floyd/end2end-paper.html, 788 Aug 1999. 790 [8] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 791 Friendly Rate Control (TFRC): Protocol Specification", 792 RFC 5348, September 2008. 794 [9] Jacobson, V., "pathchar - a tool to infer characteristics of 795 Internet paths", Presented at the Mathematical Sciences 796 Research Institute, Slides available from: 797 ftp://ftp.ee.lbl.gov/pathchar/, April 1997. 799 [10] Winstein, K., Sivaraman, A., and H. Balakrishnan, "Congestion 800 Control for Interactive Real-Time Flows on Today's Internet", 801 IAB / IRTF Workshop on Congestion Control for Interactive Real- 802 Time Communication , July 2012. 804 [11] Sarker, Z. and I. Johansson, "Improving the Interactive Real- 805 Time Video Communication with Network Provided Congestion 806 Notification", IAB / IRTF Workshop on Congestion Control for 807 Interactive Real-Time Communication , July 2012. 809 [12] Bauer, S., Beverly, R., and A. Berger, "Measuring the state of 810 ECN readiness in servers, clients,and routers", In Proceedings 811 of the 2011 ACM SIGCOMM conference on Internet measurement 812 conference (IMC '11). ACM, New York, NY, USA, pp. 171 - 813 180, URL: http://doi.acm.org/10.1145/2068816.2068833, 814 Feb. 2011. 816 [13] Zanaty, M., "Fairness Considerations for Congestion Control", 817 IAB / IRTF Workshop on Congestion Control for Interactive Real- 818 Time Communication , July 2012. 820 [14] Welzl, M., Damjanovic, D., and S. Gjessing, "MulTFRC: TFRC with 821 weighted fairness", draft-irtf-iccrg-multfrc-01 (work in 822 progress), July 2010. 824 [15] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, 825 "Extended RTP Profile for Real-time Transport Control Protocol 826 (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. 828 [16] Jarvinen, I., Chemmagate, B., Daniel, L., Ding, A., Kojo, M., 829 and M. Isomaki, "Impact of TCP on Interactive Real-Time 830 Communication", IAB / IRTF Workshop on Congestion Control for 831 Interactive Real-Time Communication , July 2012. 833 [17] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing 834 TCP's Initial Window", draft-ietf-tcpm-initcwnd-07 (work in 835 progress), January 2013. 837 [18] Allman, M., "Comments on Bufferbloat", In SIGCOMM Comput. 838 Commun. Rev. 43, 1, pp. 30 - 37, URL: 839 http://doi.acm.org/10.1145/2427036.2427041, Jan. 2013. 841 [19] Jennings, C., Nandakumar, S., and H. Phan, "Vendors Considered 842 Harmfull", IAB / IRTF Workshop on Congestion Control for 843 Interactive Real-Time Communication , July 2012. 845 [20] Holmer, S., "On Fairness, Delay and Signaling of Different 846 Approaches to Real-time Congestion Control", IAB / IRTF 847 Workshop on Congestion Control for Interactive Real-Time 848 Communication , July 2012. 850 [21] Gettys, J. and J. Gettys, "Bufferbloat: Dark Buffers in the 851 Internet", IEEE Internet Computing, 15, pp. 95 - 96 , May/ 852 June 2011. 854 [22] Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in the 855 Internet", Communications of the ACM, Vol. 55 No. 1, Pages 57 - 856 65, URL: 857 http://cacm.acm.org/magazines/2012/1/144810-bufferbloat/, 858 Jan. 2012. 860 [23] Wikipedia, "Bufferbloat", URL: 861 http://en.wikipedia.org/wiki/Bufferbloat, Jan. 2012. 863 [24] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., 864 Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, 865 C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, 866 J., and L. Zhang, "Recommendations on Queue Management and 867 Congestion Avoidance in the Internet", RFC 2309, April 1998. 869 [25] Feng, W., Shin, K., Kandlur, D., and D. Saha, "The BLUE Active 870 Queue Management Algorithm", In IEEE/ACM Transactions on 871 Networking, 10(4), pp. 513 - 528 , August 2002. 873 [26] Jarvinen, I., Ding, A., Nyrhinen, A., and M. Kojo, "Harsh RED: 874 Improving RED for Limited Aggregate Traffic", In Proceedings of 875 the 26th IEEE International Conference on Advanced Information 876 Networking and Applications (AINA 2012) , March 2012. 878 [27] IETF, "IETF IP Performance Metrics (ippm) Working Group", 879 Jan. 2012. 881 [28] Schulzrinne, H., Johnston, W., and J. Miller, "Large-Scale 882 Measurement of Broadband Performance: Use Cases, Architecture 883 and Protocol Requirements", 884 draft-schulzrinne-lmap-requirements-00 (work in progress), 885 September 2012. 887 [29] McKenney, P., "Stochastic Fairness Queuing", In IEEE INFOCOM'90 888 Proceedings, pp. 733 - 740 , June 1990. 890 [30] Nichols, K., "Controlled Delay Active Queue Management", 891 draft-nichols-tsvwg-codel-00 (work in progress), July 2012. 893 [31] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low 894 Extra Delay Background Transport (LEDBAT)", RFC 6817, 895 December 2012. 897 [32] Welzl, M., "One control to rule them all", IAB / IRTF Workshop 898 on Congestion Control for Interactive Real-Time Communication , 899 July 2012. 901 [33] Leslie, J., "There is No Magic Transport Wand", IAB / IRTF 902 Workshop on Congestion Control for Interactive Real-Time 903 Communication , July 2012. 905 [34] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN 906 - Simple Traversal of User Datagram Protocol (UDP) Through 907 Network Address Translators (NATs)", RFC 3489, March 2003. 909 [35] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 910 Protocol for Network Address Translator (NAT) Traversal for 911 Offer/Answer Protocols", RFC 5245, April 2010. 913 [36] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 914 Security Version 1.2", RFC 6347, January 2012. 916 [37] IETF, "IETF RTP Media Congestion Avoidance Techniques (rmcat) 917 Working Group", Jan. 2012. 919 [38] Bauer, S., Greenberg, A., Maltz, D., Padhye, J., Patel, P., 920 Prabhakar, B., Sengupta, S., and M. Sridharan, "Data center TCP 921 (DCTCP)", In Proceedings of the ACM SIGCOMM 2010 conference 922 (SIGCOMM '10), New York, NY, USA, pp. 63-74, URL: 923 http://doi.acm.org/10.1145/1851182.1851192, Aug. 2010. 925 [39] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. 926 Weiss, "An Architecture for Differentiated Services", RFC 2475, 927 December 1998. 929 [40] Belshe, M., Peon, R., Thomson, M., and A. Melnikov, "Hypertext 930 Transfer Protocol version 2.0", draft-ietf-httpbis-http2-01 931 (work in progress), January 2013. 933 [41] Mathis, M., "Position paper on CC for Interactive RT", IAB / 934 IRTF Workshop on Congestion Control for Interactive Real-Time 935 Communication , July 2012. 937 Appendix A. Program Committee 939 This workshop was organized by Harald Alvestrand, Bernard Aboba, Mary 940 Barnes, Gonzalo Camarillo, Spencer Dawkins, Lars Eggert, Matthew 941 Ford, Randell Jesup, Cullen Jennings, Jon Peterson, Robert Sparks, 942 and Hannes Tschofenig. 944 Appendix B. Workshop Material 946 o Main Workshop Page: 947 http://www.iab.org/activities/workshops/cc-workshop/ 949 o Position Papers: 950 http://www.iab.org/activities/workshops/cc-workshop/papers/ 952 o Slides: 953 http://www.iab.org/activities/workshops/cc-workshop/slides/ 955 Appendix C. Accepted Position Papers 957 1. "One control to rule them all" by Michael Welzl 959 2. "Congestion Avoidance Through Deterministic" by Pier Luca 960 Montessoro, Riccardo Bernardini, Franco Blanchini, Daniele 961 Casagrande, Mirko Loghi, and Stefan Wieser 963 3. "Congestion Control in Real Time Media - Context" by Harald 964 Alvestrand 966 4. "Improving the Interactive Real-Time Video Communication with 967 Network Provided Congestion Notification" by ANM Zaheduzzaman 968 Sarker, Ingemar Johansson 970 5. "Multiparty Requirements in Congestion Control for Real-Time 971 Interactive Media" by Magnus Westerlund 973 6. "On Fairness, Delay and Signaling of Different Approaches to 974 Real-time Congestion Control" by Stefan Holmer 976 7. "RTP Congestion Control and RTCWeb Application Feedback" by Ted 977 Hardie 979 8. "Issues with Using Packet Delays and Inter-arrival Times for 980 Inference of Internet Congestion" by Wesley M. Eddy 982 9. "Impact of TCP on Interactive Real-Time Communication" by Ilpo 983 Jarvinen, Binoy Chemmagate, Laila Daniel, Aaron Yi Ding, Markku 984 Kojo, and Markus Isomaki 986 10. "Security Concerns For RTCWeb Congestion Control" by Dan York 988 11. "Vendors Considered Harmfull" by Cullen Jennings, Suhas 989 Nandakumar, and Hein Phan 991 12. "Network-Assisted Dynamic Adaptation" by Xiaoqing Zhu and Rong 992 Pan 994 13. "Congestion Control for Interactive Real-Time Applications" by 995 Sanjeev Mehrotra, and Jin Li 997 14. "There is No Magic Transport Wand" by John Leslie 999 15. "Towards Adaptive Congestion Management for Interactive Real- 1000 Time Communications" by Dirk Kutscher, and Miriam Kuehlewind 1002 16. "Enlarge the pre-congestion spectrum usage?" by Xavier Marjou, 1003 and Emile Stephan 1005 17. "Congestion control for users who don't have first-class 1006 internet access" by Maire Reavy 1008 18. "Realtime Congestion Challenges" by Randell Jesup 1010 19. "Congestion Control for Interactive Media: Control Loops & APIs" 1011 by Varun Singh, Joerg Ott, and Colin Perkins 1013 20. "Some Notes on Threat Modelling Congestion Management" by Eric 1014 Rescorla 1016 21. "Timely Detection of Lost Packets" by Ali C. Begen 1018 22. "Congestion Control Considerations for Data Channels" by Michael 1019 Tuexen 1021 23. "Position paper on CC for Interactive RT" by Matt Mathis 1023 24. "Overall Considerations for Congestion Control" by M. Zanaty, B. 1024 VerSteeg, B. Christensen, D. Benham, A. Romanow 1026 25. "Fairness Considerations for Congestion Control" by Mo Zanaty 1028 26. "Media is not Data: The Meaning of Fairness for Competing 1029 Multimedia Flows" by Timothy B. Terriberry 1031 27. "Thoughts on Real-Time Congestion Control" by Murari Sridharan 1033 28. "Congestion Control for Interactive Real-Time Flows on Today's 1034 Internet" by Keith Winstein, Anirudh Sivaraman, and Hari 1035 Balakrishnan 1037 29. "Congestion Control Principles for CoAP" by Carsten Bormann, 1038 Klaus Hartke 1040 30. "Erasure Coding and Congestion Control for Interactive Real-Time 1041 Communication" by Pierre-Ugo Tournoux, Tuan Tran Thai, Emmanuel 1042 Lochin, Jerome Lacan, Vincent Roca 1044 31. "Video Conferencing Specific Considerations for RTP Congestion 1045 Control" by Stephen Botzko and Mary Barnes 1047 32. "The Internet is Broken, and How to Fix It" by Jim Gettys 1048 33. "Deployment Considerations for Congestion Control in Real-Time 1049 Interactive Media Systems" by Jari Arkko 1051 Appendix D. Workshop Participants 1053 We would like to thank the following workshop participants for 1054 attending the workshop: 1056 o Mat Ford 1058 o Bernard Aboba 1060 o Alissa Cooper 1062 o Mary Barnes 1064 o Lars Eggert 1066 o Harald Alvestrand 1068 o Gonzalo Camarillo 1070 o Robert Sparks 1072 o Cullen Jennings 1074 o Dirk Kutscher 1076 o Carsten Bormann 1078 o Michael Welzl 1080 o Magnus Westerlund 1082 o Colin Perkins 1084 o Murari Sridharan 1086 o Klaus Hartke 1088 o Pier Luca Montessoro 1090 o Xavier Marjou 1092 o Vincent Roca 1094 o Wes Eddy 1096 o Ali C. Begen 1097 o Mo Zanaty 1099 o Jin Li 1101 o Dave Thaler 1103 o Bob Briscoe 1105 o Barry Leiba 1107 o Jari Arkko 1109 o Stewart Bryant 1111 o Martin Stiemerling 1113 o Russ Housley 1115 o Marc Blanchet 1117 o Zaheduzzaman Sarker 1119 o Xiaoqing Zhu 1121 o Randell Jesup 1123 o Eric Rescorla 1125 o Suhas Nandakumar 1127 o Hannes Tschofenig 1129 o Bill VerSteeg 1131 o Sean Turner 1133 o Keith Winstein 1135 o Jon Peterson 1137 o Maire Reavy 1139 o Michael Tuexen 1141 o Stefan Holmer 1143 o Joerg Ott 1144 o Timothy Terriberry 1146 o Benoit Claise 1148 o Ted Hardie 1150 o Stephen Botzko 1152 o Matt Mathis 1154 o David Benham 1156 o Jim Gettys 1158 o Spencer Dawkins 1160 o Sanjeev Mehrotra 1162 o Adrian Farrel 1164 o Greg White 1166 o Markku Kojo 1168 We also had remote participants, namely 1170 o Emmanuel Lochin 1172 o Mark Handley 1174 o Anirudh Sivaraman 1176 o John Leslie 1178 o Varun Singh 1180 Authors' Addresses 1182 Hannes Tschofenig 1183 Linnoitustie 6 1184 Espoo, 02600 1185 Finland 1187 Phone: +358 (50) 4871445 1188 Email: Hannes.Tschofenig@gmx.net 1189 URI: http://www.tschofenig.priv.at 1191 Lars Eggert 1192 Sonnenallee 1 1193 Kirchheim, 85551 1194 Germany 1196 Phone: +49 151 12055791 1197 Email: lars@netapp.com 1198 URI: http://eggert.org/ 1200 Zaheduzzaman Sarker 1201 Lulea, SE-971 28 1202 Sweden 1204 Phone: +46 10 717 37 43 1205 Email: zaheduzzaman.sarker@ericsson.com