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