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