diff options
Diffstat (limited to 'doc/rfc/rfc7295.txt')
| -rw-r--r-- | doc/rfc/rfc7295.txt | 1459 |
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc7295.txt b/doc/rfc/rfc7295.txt new file mode 100644 index 0000000..62bd270 --- /dev/null +++ b/doc/rfc/rfc7295.txt @@ -0,0 +1,1459 @@ + + + + + + +Internet Architecture Board (IAB) H. Tschofenig +Request for Comments: 7295 L. Eggert +Category: Informational Z. Sarker +ISSN: 2070-1721 July 2014 + + + Report from the IAB/IRTF Workshop on Congestion Control + for Interactive Real-Time Communication + +Abstract + + This document provides a summary of the IAB/IRTF Workshop on + 'Congestion Control for Interactive Real-Time Communication', which + took place in Vancouver, Canada, on July 28, 2012. The main goal of + the workshop was to foster a discussion on congestion control + mechanisms for interactive real-time communication. This report + summarizes the discussions and lists recommendations to the Internet + Engineering Task Force (IETF) community. + + The views and positions in this report are those of the workshop + participants and do not necessarily reflect the views and positions + of the authors, the Internet Architecture Board (IAB), or the + Internet Research Task Force (IRTF). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Architecture Board (IAB) + and represents information that the IAB has deemed valuable to + provide for permanent record. It represents the consensus of the + Internet Architecture Board (IAB). Documents approved for + publication by the IAB are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7295. + + + + + + + + + + + + +Tschofenig, et al. Informational [Page 1] + +RFC 7295 Congestion Control Workshop Report July 2014 + + +Copyright Notice + + Copyright (c) 2014 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Workshop Structure . . . . . . . . . . . . . . . . . . . . . 5 + 2.1. History and Current Challenges . . . . . . . . . . . . . 5 + 2.2. Simulations and Measurements . . . . . . . . . . . . . . 8 + 2.3. Design Aspects of Problems and Solutions . . . . . . . . 9 + 3. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 13 + 3.1. Changes to Network Infrastructure . . . . . . . . . . . . 14 + 3.2. Avoiding Self-Inflicted Queuing . . . . . . . . . . . . . 15 + 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 6. Informative References . . . . . . . . . . . . . . . . . . . 17 + Appendix A. Program Committee . . . . . . . . . . . . . . . . . 22 + Appendix B. Workshop Material . . . . . . . . . . . . . . . . . 22 + Appendix C. Accepted Position Papers . . . . . . . . . . . . . . 22 + Appendix D. Workshop Participants . . . . . . . . . . . . . . . 24 + + + + + + + + + + + + + + + + + + + + + + +Tschofenig, et al. Informational [Page 2] + +RFC 7295 Congestion Control Workshop Report July 2014 + + +1. Introduction + + The Internet Architecture Board (IAB) holds occasional workshops + designed to consider long-term issues and strategies for the + Internet, and to suggest future directions for the Internet + architecture. This long-term planning function of the IAB is + complementary to the ongoing engineering efforts performed by working + groups of the Internet Engineering Task Force (IETF), under the + leadership of the Internet Engineering Steering Group (IESG) and area + directorates. + + Any application that sends significant amounts of data over the + Internet is expected to implement reasonable congestion control + behavior. The goals for congestion control are well understood and + documented in RFC 2914 [2] and RFC 5405 [1]: + + 1. Preventing congestion collapse. + + 2. Allowing multiple flows to share the network fairly. + + The Internet has been used for interactive real-time communication + for decades, most of which is being transmitted using the Real-Time + Transport Protocol (RTP) over UDP, often over provisioned capacity + and/or using only rudimentary congestion control mechanisms. In + 2004, the IAB raised concerns regarding possibilities of a congestion + collapse due to a rapid growth in real-time voice traffic that does + not practice end-to-end congestion control [17]. That congestion + collapse did not happen, but concerns raised about both congestion + collapse and fairness are still valid and have gained more relevance + when applied to more bandwidth-hungry video applications. The + development and upcoming widespread deployment of web-based real-time + media communication -- where RTP is used to and from web browsers to + transmit audio, video, and data -- will likely result in substantial + new Internet traffic. Due to the projected volume of this traffic, + as well as the fact that it is more likely to use unprovisioned + capacity, it is essential that it is transmitted with robust and + effective congestion control mechanisms. + + Designing congestion control mechanisms that perform well under a + wide variety of traffic mixes and over network paths with widely + varying characteristics is not easy. Prevention of congestion + collapse can be achieved through a "circuit breaker" mechanism (see, + for example, [3]), but for media flows that are supposed to coexist + with a user's other ongoing communication sessions, a congestion + control mechanism that shares capacity fairly in the presence of a + mix of TCP, UDP, and other protocol flows is needed. + + + + + +Tschofenig, et al. Informational [Page 3] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + Many additional complications arise. Here are some examples: + + 1. Real-time interactive media sessions require low latencies, + whereas streaming media can use large play-out buffers. + + 2. In an RTP session, feedback exchanged via the RTP Control + Protocol (RTCP) typically arrives much less frequently than, for + example, TCP ACKs for a given TCP connection. Theoretically, the + RTP/RTCP control loop can lead to a longer reaction time. + + 3. Media codecs can usually only adjust their output rates in a much + more coarse-grained fashion than, for example, TCP, and user + experience suffers if encoding rates are switched too frequently. + Codecs typically have a minimum sending rate as well. + + 4. Some bits of an encoded media stream are more important than + others. For example, losing or dropping an I-frame of a video + stream is more problematic than dropping a P-frame [40]. + + 5. Ramping up the transmission rate can be problematic. Simply + increasing the output rate of the codec without knowing whether + the network path can sustain transmission at the increased rate + runs the danger of incurring a significant amount of packet loss + that can cause playback artifacts. + + 6. A congestion control scheme for interactive media needs to handle + bundles of interrelated flows (audio, video, and data) in a way + that accommodates the preferences of the application in the event + of congestion. + + 7. The desire to provide a congestion control mechanism that can be + efficiently implemented inside an application imposes additional + restrictions. For example, a web browser is not able to take the + protocol interactions of a software download happening in another + application into account. + + 8. There are explicit congestion signals (such as Explicit + Congestion Notification (ECN) [19]), and there are implicit + indications of congestion (e.g., packet delay and loss). Care + must be taken to account for each of these signals, particularly + if various applications react on the same set of signals. + + 9. Large buffers are often used in network elements and end device + operating systems to better support TCP-based applications. + These buffers introduce additional communication delay, which + harms the small delay budget available for interactive real-time + applications. + + + + +Tschofenig, et al. Informational [Page 4] + +RFC 7295 Congestion Control Workshop Report July 2014 + + +2. Workshop Structure + + The IETF has a long history of work on congestion control mechanisms. + With ongoing standardization work on real-time interactive media + communication on the web, new challenges have emerged that have + refocused engineering attention on congestion control issues. To + take a deeper look at congestion control in light of the growth of + real-time traffic, workshop participants were invited to submit + position papers that were then used to organize the workshop agenda + into three principal components: a keynote talk given by Mark Handley + describing the history of the work on congestion control for real- + time media followed and his views of current problems; a presentation + of simulations and data demonstrating current problems and solutions; + and a discussion of desirable solution properties and challenges in + deploying solutions. + +2.1. History and Current Challenges + + Mark Handley argued that since 1988, the Internet has remained + functional despite exponential growth, routers that are sometimes + buggy or misconfigured, rapidly changing applications and usage + patterns, and flash crowds. This is largely because most + applications use TCP, and TCP implements end-to-end congestion + control. + + TCP's congestion control adapts the window to fit the capacity + available in the network and accomplishes approximate fairness + between two competing flows over a period of time. Mark indicated + that the provided level of fairness is not necessarily what we want: + The 1/round-trip-time relationship in TCP is not ideal since it means + that network operators can decide to lower packet loss by adding + bigger buffers (which unfortunately leads to bufferbloat problems; + see [31] and [39]). The 1/sqrt(packet drop rate) relationship is + also not necessarily desirable since TCP initially did not work + particularly well for high-speed flows (which had been the subject of + much TCP research). + + TCP controls the congestion window in bytes. For bulk transfer, + usually this results in controlling the number of 1500-byte packets + sent per second. Real-time media is different since it has its own + time constraints. For audio, one wants to send one packet per 20 ms + and for video, the ideal value would be 25 to 30 frames per second. + One, therefore, wants to avoid additional sending delay. + + As an example, in case of video, to relieve congestion one has to + reduce the number of packets-per-second transmission rate rather than + transmit smaller packets, since at higher bitrates on WiFi the time + it takes to send a packet is almost negligible compared to the time + + + +Tschofenig, et al. Informational [Page 5] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + that is spent with Media Access Control (MAC) layer operations. + Reducing the packet size makes little difference to the available + capacity. For a serial line, it does not matter how big the packets + are. + + From a network point of view, the goals of congestion control + therefore are: + + 1. Avoid congestion collapse + + 2. Avoid starvation of TCP flows + + 3. Avoid starvation of real-time flows, specifically in the case + where TCP and real-time flows share the same FIFO queue. + + From an application point of view, the goals of congestion control + are different, namely: + + 1. Robust behavior. One wants to have a good throughput when the + network is working well and passable performance when the network + is working poorly. + + 2. Predictable behavior. This matters from a usability point of + view since variable media creates a bad user experience. + + 3. Low latency. With large buffers along the end-to-end path, + latency will increase when interactive real-time flows compete + with TCP flows. This results in TCP filling up the buffers; + increased buffering will lead to additional delays for the + delivery of the interactive real-time media. + + Attempts to provide congestion control for interactive real-time + media have previously been made in the IETF, for example, with the + work on TCP Friendly Rate Control (TFRC) [12]. TFRC illustrates the + challenges quite well. TFRC tries to accomplish the same throughput + as TCP, but with a smoother transmission rate. It measures the loss + and the round-trip time but follows a similar model as TCP to + determine the sending rate. + + In a link with low statistical multiplexing, TCP can lead to bad + oscillations. The sending rate hits the maximum rate of a bottleneck + link, a lot of loss occurs, and then the sending rate peaks again. + For very small buffers the result is acceptable, but bigger buffers + lead to oscillations. The result is bad for networks and for + applications. To deal with large buffers on these links, a short- + term rate adaptation based on round-trip time (RTT) information is + utilized in TRFC, but this requires good short-term RTT measurements. + + + + +Tschofenig, et al. Informational [Page 6] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + TRFC works pretty well in theory. TFRC assumes the network is in + charge of the codec and that the codec can produce data at the + demanded rate. Modern video codecs inherently produce variable- + bitrate video streams based on the content being encoded, and it is + hard to produce data at exactly the desired bitrate without excessive + buffering or ugly quality changes. + + What if the codec is put in charge instead of the network? The + network tells the codec the mean rate, but it does not worry about + what happens in short time scales, and the codec matches the mean + rate and does not worry whether it is over or under the rate for a + relatively short time scale. This again leads to the low statistical + multiplexing problem and leads to oscillations. + + Known congestion control mechanisms work well if they can respond + quickly enough to changes and if they do not bump into the low + statistical multiplexing problem. + + To avoid the low statistical multiplexing problem, techniques for + inferring link speed are needed. The work from Van Jacobson's + pathchar [37] (and successors) serve as valuable input. The idea is + to send short packet trains, to measure timing accurately, and to + infer the link speed from the relative delay. If we know the link + speed, we can avoid exceeding it. Congestion control can give us an + approximate rate, but we must not exceed link speed. This is a + hybrid between codec being in charge (most of the time) and the + network being in charge. These work well for some links, but not for + others. Wireless links where speed can change in less than a single + RTT because of fading, bitrate adaption, etc., cause problems. We + would like to have the codec and the network be in charge. However, + they both cannot be in charge at the same time. + + Mark indicated that he is not entirely sure whether RTCP is suitable + for congestion control. RTCP gives feedback, but it cannot send it + often enough to avoid bumping into link speed. Circuit breakers [3], + on the other hand, do not help to give good performance on an + uncongested path. With circuit breakers, the sender measures the + loss rate and RTT, and runs with a loose "cap." + + In conclusion, Mark Handley claimed that we know how to do good + congestion control, but only if congestion control is in charge, and + that's not acceptable for real-time applications. We only know how + to do good congestion control if we change the packet/sec rate and + not the packet size. + + + + + + + +Tschofenig, et al. Informational [Page 7] + +RFC 7295 Congestion Control Workshop Report July 2014 + + +2.2. Simulations and Measurements + + This second part of the workshop was focused on the presentation and + the discussion of data gathered from simulations and real-world + measurements. + + Keith Winstein started the discussion with his presentation of + measurements performed in cellular operator networks in the US [22]. + The measurements indicate that the analyzed cellular networks showed + varying RTT with transient latency spikes to hundreds of + milliseconds, link speed that varies by a factor of 10 in a short + time scale, and buffers that do not drop packets until they contain + 5-10 seconds of data at bottleneck link speed. + + Zaheduzzaman Sarker [21] presented results from real-time video + communication in a Long Term Evolution (LTE) simulator utilizing ECN- + based packet marking and adaptation using implicit methods like + packet loss and delay. ECN marking provides ways for the network to + explicitly signal congestion and hence distributes the cost of + congestion well and helps achieve lower latency. However, although + RFC 3168 [19] was finalized in 2001, the deployment of ECN is still + lacking as investigated by Bauer, et al. [25]. A few participants + noted that they believe that the deployment of LTE networks will also + increase the deployment of ECN with the recent work on ECN for RTP + over UDP [11]. + + Mo Zahaty [20] discussed TFRC [12] and TFRC with weighted fairness + (MulTFRC) [4], which tunes TFRC to consider multiple flows, and + showed the impact of RTT and loss rates on the type of video quality + that can be achieved under those conditions. TFRC requires frequent + feedback, which RTCP does not provide even when considering the + extended RTP profile for RTCP-based feedback (RFC 4585 [5]). Mo + argued that application-specified weighted fairness is important but + while MulTFRC provides better performance than TFRC, it is not clear + whether the added complexity over an n-times-TFRC approach is indeed + worth the effort. + + Markku Kojo shared analysis results of how real-time audio is + affected by competing TCP flows. In the experiments shown in + Figure 2 of [27], a real-time interactive audio stream had to compete + against one TCP flow and, as a comparison, against six TCP flows. + With one concurrent TCP flow, voice is impacted on startup and six + TCP flows destroy the quality of the call. Two types of losses were + analyzed, namely losses that result from a packet being dropped in + the network (e.g., due to congestion or link errors) and losses that + result from the delayed arrival of the packet (due to buffering) when + the audio packet misses the deadline for the codec to decode and play + the transmitted content. Consequently, even a moderate number of TCP + + + +Tschofenig, et al. Informational [Page 8] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + flows typically used by browsers to retrieve content on web pages in + parallel causes irreparable harm for audio transfers. The size of + the initial window (IW) also impacts interactive real-time + communication since a larger TCP IW size (e.g., IW10 with ten + segments, as proposed in [18], instead of three) leads to a bigger + burst of packets because of the initial window transmission. Note + that the study in [24] does not necessarily lead to the same + conclusion. It claims that the increased initial window size leads + to no impact or only modest impact for buffering in the majority of + cases. + + Cullen Jennings [28] presented measurement results showing + interactions between RTP and TCP flows for several widely deployed + video communication products: Apple FaceTime, Google Hangout, Cisco + Movi, and Microsoft Skype. While all tested products implemented + some form of congestion control, none of the applications did + additive increase and multiplicative decrease (AIMD). In general, it + was observable that video adapts more slowly than AIMD to changes in + available bandwidth because most codecs cannot make small increases + in sending rates when available bandwidth increases, and do not make + large decreases in sending rates when available bandwidth decreases, + in order to improve the user's experience. + + Stefan Holmer [43] investigated the difference between loss-based and + delay-based congestion control algorithms. The suitability of loss- + based congestion control schemes for interactive real-time + communication systems heavily depends on buffer sizes and the + deployment of active queue management mechanisms. If most routers + are using tail-drop queuing, then loss-based congestion control + cannot fulfill the requirements of interactive real-time applications + since those flows will effectively increase the bitrate until a loss + event is identified, which only happens when the bottleneck queue is + full. + +2.3. Design Aspects of Problems and Solutions + + During the remaining part of the workshop, the participants discussed + design aspects of both the problem and solution spaces. The + discussions started with a presentation by Jim Gettys about problems + related to bufferbloat [31][36]. Bufferbloat is "a phenomenon in + packet-switched networks, in which excess buffering of packets causes + high latency and packet delay variation (also known as jitter), as + well as reducing the overall network throughput" [39]. A certain + amount of buffering is helpful to improve the efficiency. Not + dropping packets in the event of congestion leads to increasing + delays for interactive real-time communication. + + + + + +Tschofenig, et al. Informational [Page 9] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + Packets may get buffered at various places along the end-to-end path + including in the operating system/device drivers, customer premise + equipment (such as cable modem and DSL routers), base stations, and + routers. While the understanding of too large buffers has improved + over the last few years, workshop participants were still concerned + that many equipment manufacturers and network operators do not yet + acknowledge the existence of the problem. This lack of understanding + is caused by the strong focus on throughput network performance + measurements that do not take latency into account. For example, + only recently the Federal Communications Commission (FCC) has added + latency tests to their test suites [41]. + + Active queue management (AQM) aims to prevent queues from growing too + large. This is accomplished by monitoring queue length and informing + the sender by dropping or marking packets to lower their transmission + rate. Random Early Detection (RED) [9] is one such AQM algorithm, + but it has not been widely deployed in routers largely because of + challenges to configure it correctly [32]. According to [23], RED + does not work with the default settings as it is "too "gentle" to + handle fast changes due to TCP slow start, when the aggregate traffic + is limited." There may also be a lack of incentives to deploy AQM + algorithms. Participants speculated about the time it takes to + update network equipment (to support AQM algorithms), considering the + different replacement cycles of these devices. + + One outcome of that discussion on AQM at the workshop was a Birds of + a Feather ("BoF") meeting on "Active Queue Management and Packet + Scheduling" at IETF 87 (July 28 - August 5, 2013, Berlin, Germany). + The AQM WG [35] was chartered a few weeks later and is now designing + AQM and network infrastructure improvements to deal with bufferbloat + and related issues. + + Measurement tools that allow an end user to determine the performance + of his or her network, including latency, is seen as a promising + approach to motivate network operators to upgrade their equipment and + to make use of AQM algorithms. Measurement tools would allow users + to determine how bad their networks perform and to complain to their + ISP, thereby creating a market force. As to what the right + performance measurement metrics are, it was noted that the intent of + the IETF IP Performance Metrics (IPPM) working group [33] was to + develop such metrics to qualify networks. That work may have begun + before its time, but there have been recent attempts to revisit the + measurement work and an effort by the FCC has gotten a lot of + attention recently (see [7] and [42]). + + Matt Mathis and others argued that the traffic of throughput- + maximizing and delay-minimizing applications need to be in separate + queues (segregated queuing). Requiring segregated queues assumes you + + + +Tschofenig, et al. Informational [Page 10] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + are sharing the network with other greedy traffic. + Quality-of-Service (QoS) signaling is a way to deploy segregated + queuing, but there are several simpler alternatives, such as + Stochastic Fair Queuing [38]. The Controlled Delay (CoDel) AQM + algorithm [6] can also be used in combination with stochastic fair + queuing. Note that queue segregation is not necessary for every + router to implement; using it at the edge of a network where + bottleneck links are located is already sufficient. + + It was noted that current interactive voice usage over the Internet + works most of the time satisfactorily. In typical networks, the + reason voice works is because networks are underloaded. As long as + there is idle capacity and the queue is empty when packets arrive, + traffic does not need to be separated into distinct queues. Further + explanations were offered as to why many networks work surprisingly + well: Low Extra Delay Background Transport (LEDBAT) [8] is used for + the download of software updates, voice traffic contributes only a + small percentage of the overall Internet traffic, and users employ + "human protocols" (e.g., parents asking their kids to get off the + network during the time of a conference call). + + Cullen Jennings raised a concern that although interactive voice may + be functional without a congestion control mechanism, the potentially + large uptake of interactive video spurred on by Real-Time + Communications on the Web (RTCWEB) could create substantially more + significant problems. In the class of space where voice is currently + working, video may fail. Ted Hardie countered by saying that RTCWEB + is trying to replace existing proprietary technologies. It may ramp + up the amount of use we are expecting, but it is not doing much that + was not being done by Adobe Flash or Skype. RTCWEB is not a totally + novel context of Internet usage. Magnus Westerlund added that RTCWEB + might be the driver for the moment, but web browsers are not the only + consumers of such congestion control algorithm. + + Furthermore, Ted Hardie noted that applications will not produce + media streams that grow to 10 Mbps because their sending rate is auto + rate limited by the production of the video. He suggested to ask + ourselves if we are trying to get TCP to be friendly to media streams + that are already rate limited or if we are asking media streams that + are already rate limited to be TCP friendly. To quote Andrew + McGregor: "It's really not good to be TCP friendly because it's not + going to return the favor." If the desired properties we want are no + starvation, fairness, and effective goodput for the offered loads, + are we only willing to consider changes in RTP control, or are we + willing to consider changes in TCP congestion control? + + + + + + +Tschofenig, et al. Informational [Page 11] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + This led to a discussion about whether the development of a + congestion control algorithm for interactive real-time applications + provides any value if network equipment suffers from bufferbloat. Is + there something that can be done today to help interactive real-time + media or do we have to wait to get the network updated first? + Replacing home routers and updating routers with modern AQM + algorithms was seen as a longer-term effort. Also, the time scale + for changing TCP's congestion control is on the same time scale as + deploying ECN [19]. Colin Perkins noted that we cannot change TCP + quickly; the way TCP is being used is changing quickly, and we can + impact the way TCP is used. When TCP is used for file transfer, it + will send data as fast as it can, but when TCP is used for + WebSockets, the dynamics are different. WebSockets and SPDY are + clearly changing the behavior of TCP. Also, Netflix-style video- + streaming applications are huge users of TCP and those applications + can change rather quickly. Matt Mathis added that real-time + videoconferencing almost always produces video streams at a lower + bitrate than downloading equivalent-sized stored video using best- + effort file-sharing. + + Bill Ver Steeg suggested to consider three different deployment + environments, namely: + + 1. Flows competing with flows from the host ("self-inflicted queuing + delay") + + 2. Flows competing with flows in the same subnetwork (e.g., home + network) + + 3. Flows competing with flows from other networks (e.g., traffic + from different households that utilize the same DSL provider) + + The narrowest problem domain that makes sense is to avoid self- + inflicted queuing delay. Michael Welzl indicated that this requires + an information exchange (called flow-state exchange) inside a browser + (at the level of the same host or even beyond, as described in [29]) + to synchronize congestion control of different audio, video, and data + flows. Although it would provide great benefits if one could share + information about a bottleneck with all the flows sharing that + bottleneck, this is considered challenging even within a single host. + John Leslie [30] also noted: "We're acting as if we believe + congestion will magically be solved by a new transport algorithm. It + won't." Instead, an interaction between the network layer, transport + layer, and the application layer is needed whereby the application + layer is the only practical place to balance what piece(s) to + constrain to lower bandwidths. All flows relating to a user session + + + + + +Tschofenig, et al. Informational [Page 12] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + should have a common congestion controller. For many applications, + audio is much more critical than video. In those cases, the video + may back off, but the audio transmission remains unchanged. + + Mo Zanaty pointed to the importance of the media start-up behavior, + which is an area where the exchange of real-time interactive media is + different from a TCP-based file transfer. The instantaneous + experience in the first part of a video call is highly determinative + of people's perception of the call quality. Vendors are using vague + heuristics, for example, data from the last call to figure out what + to do on the next call. Lars Eggert highlighted that the start-up + behavior of an application affects ongoing performance of other flows + if, for example, an application blasts at line rate at the beginning + of a video stream. You need to start slow enough to not cause + congestion to others. Randell Jesup argued that for an interactive + real-time video application, you really need to have most of your + bandwidth right away. Colin Perkins agreed and added that on startup + you need good quality video quickly, but perhaps not as quickly as + voice. The requirements are likely going to be different from audio + to video and maybe even vary between different applications. Various + protocol exchanges take place before media is exchanged between + endpoints (such as Session Traversal Utilities for NAT (STUN) packets + [13] as part of the Interactive Connectivity Establishment (ICE) [15] + or a Datagram Transport Layer Security (DTLS) handshake [14]) and may + be used to obtain simple start-up measurements. + + The group agreed that it is feasible to design a congestion control + algorithm that works on mostly idle networks. In the view of the + participants, upgrades of the network infrastructure can happen in + parallel. This view was later confirmed at the RTP Media Congestion + Avoidance Techniques (RMCAT) BoF meeting at IETF 84 (July 29 - August + 3, 2012, Vancouver, BC, Canada) that led to the formation of the + RMCAT working group [34]. + +3. Recommendations + + The participants suggested to explore two primary solution tracks: + changes to network infrastructure and the development of algorithms + to avoid self-inflicted queuing. These are discussed below. A third + approach recommended by some participants was to change the way TCP + is used in browsers and other HTTP-based applications. For example, + by not opening too many concurrent TCP connections, and by improving + the interaction with other non-real-time applications (such as video + streaming and file sharing), additional improvements can be made. + The work on HTTP 2.0 with SPDY [16] is already a step in the right + direction since SPDY makes use of a more aggressive form of + multiplexing instead of opening a larger number of TCP connections. + + + + +Tschofenig, et al. Informational [Page 13] + +RFC 7295 Congestion Control Workshop Report July 2014 + + +3.1. Changes to Network Infrastructure + + As for all other traffic on the network, better data plane + infrastructure improves the perceived quality of the best-effort + service that the Internet provides for RTCWEB flows. The IETF has + already developed several technologies that would be of immediate + usefulness if they were to be deployed. The workshop participants + expressed the hope that due to the volume and importance of RTCWEB + traffic, some of these technologies might finally see widespread use. + + The first and by far most important improvement is traffic + segregation: the ability to use different queues for different + traffic types. Specifically, jitter- and delay-sensitive protocols + would benefit from being in different queues from throughput- + maximizing protocols. It is not possible for a single queue/AQM to + be optimal for both. + + Furthermore, ECN allows routers along the end-to-end path to signal + the onset of congestion and allows applications to respond early, + avoiding losses and keeping queue sizes short and, therefore, + end-to-end delay low. ECN is implemented on some end system stacks + and routers, but is frequently not enabled. The participants + expressed the importance of increasing the deployment of ECN, even if + used initially only in closed environments, such as data centers (as + with Data Center TCP (DCTCP) [26]). + + Different mechanisms have been developed to facilitate traffic + segregation. Differentiated Services [10] is one possibility in this + space. If applications start to mark outgoing traffic appropriately + and routers segregate traffic accordingly, browsers could more + directly control the relative importance of their various flows and + avoid self-competition. Compared to ECN, however, DiffServ is far + more difficult to deploy meaningfully end to end, especially given + that Differentiated Services Code Points (DSCPs) have no defined end- + to-end meaning and packets can be re-marked. + + QoS signaling together with resource reservation facilities would + enable a fine-grained and flexible way to indicate resource needs to + network elements, but it is also by far the most heavyweight + proposal, and unlikely to be viable in the global Internet. However, + as mentioned in Section 2.3, QoS signaling is not the only way to + accomplish traffic segregation. Further investigations regarding + stochastic fair queuing and new AQM algorithms are seen as desirable. + + In any case, network infrastructure updates will take time, + particularly if the interest of the involved stakeholders is not + aligned (as is often the case for network operators when dealing with + + + + +Tschofenig, et al. Informational [Page 14] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + over-the-top real-time traffic). It is, therefore, imperative that + RTCWEB congestion control provides adequate improvement in the + absence of any of the aforementioned schemes. + +3.2. Avoiding Self-Inflicted Queuing + + This approach tries to ensure that the network does not suffer from + congestion collapse and that one data flow from a single host does + not harm another data flow from the same host. A single congestion + manager within the end host or the browser could help to coordinate + various congestion control activities and to ensure a more + coordinated approach between different applications and different + flows. + + The following design and testing aspects were considered relevant to + this approach: + + Reacting to All Congestion Signals: + + To initiate the congestion control process, it is important to + detect congestion in the communication path. Congestion can be + detected using either an explicit mechanism or an implicit + mechanism. An explicit mechanism involves direct congestion + signaling usually from the congested network node, such as ECN. + In case of an implicit mechanism, packet-loss events or observed + delay increases are used as an indication for congestion. These + measurements can also be made available in a variety of different + protocols, such as RTCP reports or transport protocols. It is + recommended for applications to take all available congestion + signals into account and to couple the congestion control + algorithm, the codec, and the application so that better + information exchange between these components is possible since + there are constraints on how quickly a codec can adapt to a + specific sending rate. + + Delay- and Loss-Based Algorithms: + + The main goal of designing a congestion control algorithm for + real-time conversational media is to achieve low latency. + Explicit congestion signals provide the most reliable way for + applications to react, but due to the lack of ECN deployment, + delay-based algorithms are needed. Since there is large delay + variation in wireless networks (even in a non-congested network), + the workshop participants recommended that more research should be + done to better understand non-congestion-related delay variation + in the network. General consensus among the workshop participants + was that latency-based congestion control algorithms are needed + + + + +Tschofenig, et al. Informational [Page 15] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + due to the lack of loss indications caused by large buffers, even + though loss-based techniques dominate latency-based techniques + when the two are competing for bandwidth. + + Algorithm Evaluation: + + The Internet consists of heterogeneous networks, which include + misconfigured and unmanaged network nodes. Bandwidth and latency + vary a lot. Different services deployed using RTP/UDP have + different requirements in terms of media quality. A congestion + control algorithm needs to perform well not only in simulators but + also in the deployed Internet. To achieve this, it is recommended + to test the algorithms with real-world loss and delay figures to + ensure that the desired audio/video rates are attainable using the + proposed algorithms for the desired services. + + Media Characteristics: + + Interactive real-time voice and video data are inherently + variable. Usually the content of the media and service + requirements dictate the media coding. The codec may be bursty + and not all frames are equally important (e.g., I-frames are more + important than P-frames). Thus, codecs have limited room for + adaptation. Congestion control for audio and video codecs is, + therefore, different from congestion control applied to bulk file + transfers where buffering is not a problem and the transmission + rate can be changed to any rate suitable for the congestion + control algorithm. In the workshop, these limitations were + brought up and the workshop participants recommended that a + congestion controller needs to be aware of these constraints. + However, further investigation is needed to decide what + information needs to be exchanged between a codec and the + congestion manager. + + Start-up Behavior: + + The start-up media quality is very important for real-time + interactive applications and for user-perceived application + performance. The start-up behavior of these is also different + from other traffic. By nature, real-time interactive + communication applications want to provide a smooth user + experience and maintain the best media quality possible to ease + the interaction. While it may be desirable from a user-experience + point of view to immediately start streaming video with high- + definition quality and audio of a wideband codec, this will have + impacts on the bandwidth of the already ongoing flows. As such, + + + + + +Tschofenig, et al. Informational [Page 16] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + it would be ideal to start slow enough to avoid causing excessive + congestion to other flows but fast enough to offer a good user + experience. The sweet spot, however, yet has to be found. + +4. Security Considerations + + Two position papers focused on security, but these papers were not + discussed during the workshop. As such, nothing beyond the material + contained in those position papers can be reported. + +5. Acknowledgments + + We would like to thank the participants and the paper authors of the + position papers for their input. + + Additionally, we would like to thank the following persons for their + review comments: Michael Welzl, John Leslie, Mirja Kuehlewind, Matt + Mathis, Mary Barnes, Spencer Dawkins, Dave Thaler, and Alissa Cooper. + +6. Informative References + + [1] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for + Application Designers", BCP 145, RFC 5405, November 2008. + + [2] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, + September 2000. + + [3] Perkins, C. and V. Singh, "Multimedia Congestion Control: + Circuit Breakers for Unicast RTP Sessions", Work in Progress, + February 2014. + + [4] Welzl, M., Damjanovic, D., and S. Gjessing, "MulTFRC: TFRC with + weighted fairness", Work in Progress, July 2010. + + [5] Ott, J., Wenger, S., Sato, N., Burmeister, C., and J. Rey, + "Extended RTP Profile for Real-time Transport Control Protocol + (RTCP)-Based Feedback (RTP/AVPF)", RFC 4585, July 2006. + + [6] Nichols, K. and V. Jacobson, "Controlled Delay Active Queue + Management", Work in Progress, March 2014. + + [7] Schulzrinne, H., Johnston, W., and J. Miller, "Large-Scale + Measurement of Broadband Performance: Use Cases, Architecture + and Protocol Requirements", Work in Progress, September 2012. + + [8] Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low + Extra Delay Background Transport (LEDBAT)", RFC 6817, December + 2012. + + + +Tschofenig, et al. Informational [Page 17] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + [9] Braden, B., Clark, D., Crowcroft, J., Davie, B., Deering, S., + Estrin, D., Floyd, S., Jacobson, V., Minshall, G., Partridge, + C., Peterson, L., Ramakrishnan, K., Shenker, S., Wroclawski, + J., and L. Zhang, "Recommendations on Queue Management and + Congestion Avoidance in the Internet", RFC 2309, April 1998. + + [10] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. + Weiss, "An Architecture for Differentiated Services", RFC 2475, + December 1998. + + [11] Westerlund, M., Johansson, I., Perkins, C., O'Hanlon, P., and + K. Carlberg, "Explicit Congestion Notification (ECN) for RTP + over UDP", RFC 6679, August 2012. + + [12] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP + Friendly Rate Control (TFRC): Protocol Specification", RFC + 5348, September 2008. + + [13] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session + Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. + + [14] Rescorla, E. and N. Modadugu, "Datagram Transport Layer + Security Version 1.2", RFC 6347, January 2012. + + [15] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A + Protocol for Network Address Translator (NAT) Traversal for + Offer/Answer Protocols", RFC 5245, April 2010. + + [16] Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer + Protocol version 2", Work in Progress, June 2014. + + [17] Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion + Control for Voice Traffic in the Internet", RFC 3714, March + 2004. + + [18] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing + TCP's Initial Window", RFC 6928, April 2013. + + [19] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of + Explicit Congestion Notification (ECN) to IP", RFC 3168, + September 2001. + + [20] Zanaty, M., "Fairness Considerations for Congestion Control for + Interactive Real-Time Communication (IRTC)", IAB/ RTF Workshop + on Congestion Control for Interactive Real-Time Communication, + July 2012. + + + + + +Tschofenig, et al. Informational [Page 18] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + [21] Sarker, Z. and I. Johansson, "Improving the Interactive + Real-Time Video Communication with Network Provided Congestion + Notification", IAB/IRTF Workshop on Congestion Control for + Interactive Real-Time Communication, July 2012. + + [22] Winstein, K., Sivaraman, A., and H. Balakrishnan, "Congestion + Control for Interactive Real-Time Flows on Today's Internet", + IAB/IRTF Workshop on Congestion Control for Interactive + Real-Time Communication, July 2012. + + [23] Jarvinen, I., Ding, A., Nyrhinen, A., and M. Kojo, "Harsh RED: + Improving RED for Limited Aggregate Traffic", In Proceedings of + the 26th IEEE International Conference on Advanced Information + Networking and Applications (AINA 2012), March 2012. + + [24] Allman, M., "Comments on Bufferbloat", In ACM SIGCOMM Computer + Communication Review, Volume 43, Issue 1, pp. 30-37, January + 2013, <http://dl.acm.org/citation.cfm?doid=2427036.2427041>. + + [25] Bauer, S., Beverly, R., and A. Berger, "Measuring the state of + ECN readiness in servers, clients,and routers", In Proceedings + of the 2011 ACM SIGCOMM conference on Internet measurement + conference (IMC '11), New York, NY, USA, pp. 171-180, February + 2011, <http://dl.acm.org/citation.cfm?doid=2068816.2068833>. + + [26] Bauer, S., Greenberg, A., Maltz, D., Padhye, J., Patel, P., + Prabhakar, B., Sengupta, S., and M. Sridharan, "Data center TCP + (DCTCP)", In Proceedings of the ACM SIGCOMM 2010 conference + (SIGCOMM '10), New York, NY, USA, pp. 63-74, August 2010, + <http://dl.acm.org/citation.cfm?doid=1851182.1851192>. + + [27] Jarvinen, I., Chemmagate, B., Daniel, L., Ding, A., Kojo, M., + and M. Isomaki, "Impact of TCP on Interactive Real- Time + Communication", IAB/IRTF Workshop on Congestion Control for + Interactive Real-Time Communication, July 2012. + + [28] Jennings, C., Nandakumar, S., and H. Phan, "Vendors Considered + Harmfull", IAB/IRTF Workshop on Congestion Control for + Interactive Real-Time Communication, July 2012. + + [29] Welzl, M., "One control to rule them all", IAB/IRTF Workshop on + Congestion Control for Interactive Real-Time Communication, + July 2012. + + [30] Leslie, J., "There is No Magic Transport Wand", IAB/IRTF + Workshop on Congestion Control for Interactive Real-Time + Communication, July 2012. + + + + +Tschofenig, et al. Informational [Page 19] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + [31] Gettys, J. and J. Gettys, "Bufferbloat: Dark Buffers in the + Internet", IEEE Internet Computing, Volume 15, Issue 3, pp. + 95-96, May/June 2011. + + [32] Feng, W., Shin, K., Kandlur, D., and D. Saha, "The BLUE active + queue management algorithms", In IEEE/ACM Transactions on + Networking, Volume 10, Issue 4, pp. 513-528, August 2002. + + [33] IETF, "IP Performance Metrics (ippm) Working Group", January + 2012, <http://datatracker.ietf.org/wg/ippm/charter/>. + + [34] IETF, "RTP Media Congestion Avoidance Techniques (rmcat) + Working Group", January 2012, + <http://datatracker.ietf.org/wg/rmcat/charter/>. + + [35] IETF, "Active Queue Management and Packet Scheduling (aqm) + Working Group", September 2013, + <http://datatracker.ietf.org/wg/aqm/charter/>. + + [36] Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in the + Internet", Communications of the ACM, Vol. 55, No. 1, pp. + 57-65, January 2012, + <http://cacm.acm.org/magazines/2012/1/144810-bufferbloat/>. + + [37] Jacobson, V., "pathchar - a tool to infer characteristics of + Internet paths", Presented at the Mathematical Sciences + Research Institute, April 1997, + <ftp://ftp.ee.lbl.gov/pathchar/msri-talk.pdf>. + + [38] McKenney, P., "Stochastic Fairness Queuing", In IEEE INFOCOM'90 + Proceedings, Volume 2, pp. 733-740, June 1990. + + [39] Wikipedia, "Bufferbloat", May 2014, <http://en.wikipedia.org/w/ + index.php?title=Bufferbloat&oldid=608805474>. + + [40] Wikipedia, "Video compression picture types", March 2014, + <http://en.wikipedia.org/w/index.php? + title=Video_compression_picture_types&oldid=602183340>. + + [41] FCC, "Methodology - Measuring Broadband America July Report + 2012", July 2012, <http://www.fcc.gov/ + measuring-broadband-america/2012/methodology-july-report-2012>. + + [42] IETF, "lmap -- Large Scale Measurement of Access network + Performance Mailing List", 2012, + <https://www.ietf.org/mailman/listinfo/lmap>. + + + + + +Tschofenig, et al. Informational [Page 20] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + [43] Holmer, S., "On Fairness, Delay and Signaling of Different + Approaches to Real-time Congestion Control", IAB/IRTF Workshop + on Congestion Control for Interactive Real-Time Communication, + July 2012. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Tschofenig, et al. Informational [Page 21] + +RFC 7295 Congestion Control Workshop Report July 2014 + + +Appendix A. Program Committee + + This workshop was organized by Harald Alvestrand, Bernard Aboba, Mary + Barnes, Gonzalo Camarillo, Spencer Dawkins, Lars Eggert, Matthew + Ford, Randell Jesup, Cullen Jennings, Jon Peterson, Robert Sparks, + and Hannes Tschofenig. + +Appendix B. Workshop Material + + o Main Workshop Page: + http://www.iab.org/activities/workshops/cc-workshop/ + + o Position Papers: + http://www.iab.org/activities/workshops/cc-workshop/papers/ + + o Slides: + http://www.iab.org/activities/workshops/cc-workshop/slides/ + +Appendix C. Accepted Position Papers + + 1. "One control to rule them all" by Michael Welzl + + 2. "Congestion Avoidance Through Deterministic" by Pier Luca + Montessoro, Riccardo Bernardini, Franco Blanchini, Daniele + Casagrande, Mirko Loghi, and Stefan Wieser + + 3. "Congestion Control in Real Time Media - Context" by Harald + Alvestrand + + 4. "Improving the Interactive Real-Time Video Communication with + Network Provided Congestion Notification" by ANM Zaheduzzaman + Sarker and Ingemar Johansson + + 5. "Multiparty Requirements in Congestion Control for Real-Time + Interactive Media" by Magnus Westerlund + + 6. "On Fairness, Delay and Signaling of Different Approaches to + Real-time Congestion Control" by Stefan Holmer + + 7. "RTP Congestion Control and RTCWEB Application Feedback" by Ted + Hardie + + 8. "Issues with Using Packet Delays and Inter-arrival Times for + Inference of Internet Congestion" by Wesley M. Eddy + + 9. "Impact of TCP on Interactive Real-Time Communication" by Ilpo + Jarvinen, Binoy Chemmagate, Laila Daniel, Aaron Yi Ding, Markku + Kojo, and Markus Isomaki + + + +Tschofenig, et al. Informational [Page 22] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + 10. "Security Concerns For RTCWEB Congestion Control" by Dan York + + 11. "Vendors Considered Harmfull" by Cullen Jennings, Suhas + Nandakumar, and Hein Phan + + 12. "Network-Assisted Dynamic Adaptation" by Xiaoqing Zhu and Rong + Pan + + 13. "Congestion Control for Interactive Real-Time Applications" by + Sanjeev Mehrotra and Jin Li + + 14. "There is No Magic Transport Wand" by John Leslie + + 15. "Towards Adaptive Congestion Management for Interactive Real- + Time Communications" by Dirk Kutscher and Miriam Kuehlewind + + 16. "Enlarge the pre-congestion spectrum usage?" by Xavier Marjou + and Emile Stephan + + 17. "Congestion control for users who don't have first-class + internet access" by Maire Reavy + + 18. "Realtime Congestion Challenges" by Randell Jesup + + 19. "Congestion Control for Interactive Media: Control Loops & APIs" + by Varun Singh, Joerg Ott, and Colin Perkins + + 20. "Some Notes on Threat Modelling Congestion Management" by Eric + Rescorla + + 21. "Timely Detection of Lost Packets" by Ali C. Begen + + 22. "Congestion Control Considerations for Data Channels" by Michael + Tuexen + + 23. "Position paper on CC for Interactive RT" by Matt Mathis + + 24. "Overall Considerations for Congestion Control" by Mo Zanaty, + Bill VerSteeg, Bent Christensen, David Benham, and Allyn Romanow + + 25. "Fairness Considerations for Congestion Control" by Mo Zanaty + + 26. "Media is not Data: The Meaning of Fairness for Competing + Multimedia Flows" by Timothy B. Terriberry + + 27. "Thoughts on Real-Time Congestion Control" by Murari Sridharan + + + + + +Tschofenig, et al. Informational [Page 23] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + 28. "Congestion Control for Interactive Real-Time Flows on Today's + Internet" by Keith Winstein, Anirudh Sivaraman, and Hari + Balakrishnan + + 29. "Congestion Control Principles for CoAP" by Carsten Bormann and + Klaus Hartke + + 30. "Erasure Coding and Congestion Control for Interactive Real-Time + Communication" by Pierre-Ugo Tournoux, Tuan Tran Thai, Emmanuel + Lochin, Jerome Lacan, and Vincent Roca + + 31. "Video Conferencing Specific Considerations for RTP Congestion + Control" by Stephen Botzko and Mary Barnes + + 32. "The Internet is Broken, and How to Fix It" by Jim Gettys + + 33. "Deployment Considerations for Congestion Control in Real-Time + Interactive Media Systems" by Jari Arkko + +Appendix D. Workshop Participants + + We would like to thank the following workshop participants for + attending the workshop: + + o Mat Ford + o Bernard Aboba + o Alissa Cooper + o Mary Barnes + o Lars Eggert + o Harald Alvestrand + o Gonzalo Camarillo + o Robert Sparks + o Cullen Jennings + o Dirk Kutscher + o Carsten Bormann + o Michael Welzl + o Magnus Westerlund + o Colin Perkins + o Murari Sridharan + o Klaus Hartke + o Pier Luca Montessoro + o Xavier Marjou + o Vincent Roca + o Wes Eddy + o Ali C. Begen + o Mo Zanaty + o Jin Li + o Dave Thaler + + + +Tschofenig, et al. Informational [Page 24] + +RFC 7295 Congestion Control Workshop Report July 2014 + + + o Bob Briscoe + o Barry Leiba + o Jari Arkko + o Stewart Bryant + o Martin Stiemerling + o Russ Housley + o Marc Blanchet + o Zaheduzzaman Sarker + o Xiaoqing Zhu + o Randell Jesup + o Eric Rescorla + o Suhas Nandakumar + o Hannes Tschofenig + o Bill VerSteeg + o Sean Turner + o Keith Winstein + o Jon Peterson + o Maire Reavy + o Michael Tuexen + o Stefan Holmer + o Joerg Ott + o Timothy Terriberry + o Benoit Claise + o Ted Hardie + o Stephen Botzko + o Matt Mathis + o David Benham + o Jim Gettys + o Spencer Dawkins + o Sanjeev Mehrotra + o Adrian Farrel + o Greg White + o Markku Kojo + + We also had remote participants, namely: + + o Emmanuel Lochin + o Mark Handley + o Anirudh Sivaraman + o John Leslie + o Varun Singh + + + + + + + + + + +Tschofenig, et al. Informational [Page 25] + +RFC 7295 Congestion Control Workshop Report July 2014 + + +Authors' Addresses + + Hannes Tschofenig + Hall, Tirol 6060 + Austria + + EMail: Hannes.Tschofenig@gmx.net + URI: http://www.tschofenig.priv.at + + + Lars Eggert + Sonnenallee 1 + Kirchheim 85551 + Germany + + Phone: +49 151 12055791 + EMail: lars@netapp.com + URI: http://eggert.org/ + + + Zaheduzzaman Sarker + Lulea SE-971 28 + Sweden + + Phone: +46 10 717 37 43 + EMail: zaheduzzaman.sarker@ericsson.com + + + + + + + + + + + + + + + + + + + + + + + + + +Tschofenig, et al. Informational [Page 26] + |