Skip to main content

Report from the IAB/IRTF Workshop on Congestion Control for Interactive Real-Time Communication

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7295.
Authors Hannes Tschofenig , Lars Eggert , Zaheduzzaman Sarker
Last updated 2013-01-31
Replaces draft-tschofenig-cc-workshop-report
RFC stream Internet Architecture Board (IAB)
Stream IAB state (None)
Consensus boilerplate Unknown
IAB shepherd (None)
Network Working Group                                      H. Tschofenig
Internet-Draft                                                 L. Eggert
Intended status: Informational                                 Z. Sarker
Expires: August 3, 2013                                 January 30, 2013

Report from the IAB/IRTF Workshop on Congestion Control for Interactive
                        Real-Time Communication


   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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 3, 2013.

Copyright Notice

   Copyright (c) 2013 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

Tschofenig, et al.       Expires August 3, 2013                 [Page 1]
Internet-Draft     Congestion Control Workshop Report       January 2013

   Provisions Relating to IETF Documents
   ( 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Workshop Structure . . . . . . . . . . . . . . . . . . . . . .  5
     2.1.  History and Challenges . . . . . . . . . . . . . . . . . .  5
     2.2.  Simulations and Measurements . . . . . . . . . . . . . . .  8
     2.3.  Challenges and Design Properties . . . . . . . . . . . . .  9
   3.  Recommendations  . . . . . . . . . . . . . . . . . . . . . . . 14
     3.1.  Changes to Network Infrastructure  . . . . . . . . . . . . 14
     3.2.  Avoiding Self-Inflicted Queuing  . . . . . . . . . . . . . 15
   4.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 21
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Appendix A.  Program Committee . . . . . . . . . . . . . . . . . . 25
   Appendix B.  Workshop Material . . . . . . . . . . . . . . . . . . 26
   Appendix C.  Accepted Position Papers  . . . . . . . . . . . . . . 27
   Appendix D.  Workshop Participants . . . . . . . . . . . . . . . . 30
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33

Tschofenig, et al.       Expires August 3, 2013                 [Page 2]
Internet-Draft     Congestion Control Workshop Report       January 2013

1.  Introduction

   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 [1] and RFC 5405 [2]:

   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 RTP over UDP,
   often over provisioned capacity and/or using only rudimentary
   congestion control mechanisms.

   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.

   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 Real-time Transport Protocol (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.

Tschofenig, et al.       Expires August 3, 2013                 [Page 3]
Internet-Draft     Congestion Control Workshop Report       January 2013

   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 [4].

   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, data), in a way that
       accommodates the preferences of the application in the event of

   7.  The desire to provide a congestion control mechanism that can be
       efficiently implemented inside an application (e.g., a web server
       and a browser) imposes additional restrictions.

   8.  There are explicit congestion signals (such as Explicit
       Congestion Notification (ECN) [5]), 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

   The Internet Architecture Board (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 in early 2004 [6].  This congestion collapse did not happen
   but the raised concerns are still valid and have gained more
   relevance when applied to more bandwidth-hungry video applications.
   Congestion collapse is, however, not the only concern as discussed in
   this workshop report.

Tschofenig, et al.       Expires August 3, 2013                 [Page 4]
Internet-Draft     Congestion Control Workshop Report       January 2013

2.  Workshop Structure

   The IETF has a long history in the work on congestion control
   mechanisms but with the ongoing standardization work on real-time
   interactive media communication on the Web new challenges emerged and
   existing work got revisited.  To take a deeper look at the topic the
   participants contributed 32 papers as input to the one-day workshop.

   The workshop started with a keynote speech of Mark Handley describing
   the history of the work on congestion control for real-time media
   followed with his views of the problems.  A summary of the
   discussions and the identified issues are captured in the subsections

2.1.  History and Challenges

   The primary goal of congestion control is to avoid congestion
   collapse - to make the network work.  The second important goal is to
   guarantee some sort of fairness so that all users get some service.
   Section 3 of RFC 2914 [1] discusses these two goals in detail and
   references earlier work, such as [7]. [7] informs about historic
   incidents, such as congestion collapse due to unnecessarily-
   retransmitted, undelivered, and fragmented packets.

   Mark Handley argues 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

   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 indicates
   that the provided level of fairness is not necessarily what we want:
   The 1/round-trip-time relationship in TCP is not wonderful since it
   means that network operators can decide to lower packet loss by
   adding bigger buffers (which unfortunately leads to bufferbloat
   problems).  The 1/sqrt(packet drop rate) relationship is also not
   necessarily desirable since TCP did not work particularly well for
   high-speed flows (which had been subject for a lot of TCP research).

   TCP controls the congestion window in bytes.  For bulk transfer,
   usually this results in controlling the number of 1500 byte packets
   per second sent.  Real-time media is, however, different since it has
   its own time constraints.  For audio we want to send one packet per
   20ms and for video the ideal value would be 25 to 30 frames per
   second.  We therefore want to avoid additional sending delay.

Tschofenig, et al.       Expires August 3, 2013                 [Page 5]
Internet-Draft     Congestion Control Workshop Report       January 2013

   As an example, in case of video, to relieve congestion one has to
   reduce the number of packets-per-second transmission rate rather than
   transmitting smaller packets since at higher bitrates on WiFi the
   time it takes to send a packet is almost negligible compared to the
   time that is spent with 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 it still works when the network is
       working poorly.

   2.  Predictable behavior.  This matters from a usability point of
       view since variable media quality is bad for users.

   3.  Low latency.  With large buffers along the end-to-end path the
       latency will increase when interactive real-time flows compete
       with TCP flows since TCP will fill up the buffers and the
       increased buffering leads to additional delays for the delivery
       of the interactive real-time media.

   Attempts for providing congestion control for interactive real-time
   media were already done much earlier in the IETF, for example, with
   the work on TCP-Friendly Rate Control (TFRC) [8].  It illustrates the
   challenges quite well.  TFRC tries to accomplish the same throughput
   as TCP, but with 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

Tschofenig, et al.       Expires August 3, 2013                 [Page 6]
Internet-Draft     Congestion Control Workshop Report       January 2013

   rate adaptation based on round-trip time (RTT) information is
   utilized in TRFC but this requires good short-term RTT measurements.

   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 we put the codec 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 if they do not bump into the low
   statistical multiplexing problem.

   To avoid the low statistical multiplexing problem techniques for
   inferring linkspeed are needed and the work from Van Jacobson's
   pathchar [9] (and successors) serve as valuable input.  The idea is
   to send short packet trains, to measure timing accurately, and to
   infer the linkspeed from the relative delay.  If we know the
   linkspeed, we can avoid exceeding it.  Congestion control can give us
   an approximate rate, but we must not exceed linkspeed.  This is a
   hybrid between codec being in charge (most of the time), and 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 to be in charge.  However,
   they cannot be both 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 linkspeed." he says.  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".

   As a conclusion, Mark Handley claims 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 packet/sec rate and not
   packet size.

Tschofenig, et al.       Expires August 3, 2013                 [Page 7]
Internet-Draft     Congestion Control Workshop Report       January 2013

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

   Keith Winstein started the discussion with his presentation of
   measurements performed in cellular operator networks in the US [10].
   The measurements indicate that the analyzed cellular networks showed
   varying RTT with transient latency spikes to hundreds of ms, 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 [11] presented results from real-time video
   communication in an 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 hence distributes the cost of congestion well and helps
   achieving lower latency.  However, although RFC 3168 [5] was
   finalized in 2001 the deployment of ECN is still lacking as
   investigated by Bauer, et al. [12].  A few participants noted that
   they believe that the deployment of LTE networks will also increase
   the deployment of ECN.

   Mo Zahaty [13] discussed TFRC [8] and TFRC with weighted fairness
   (MulTFRC) [14], 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 [15]).  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 [16] 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 quality of 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
   flows typically used by browsers to retrieve content on Web pages in

Tschofenig, et al.       Expires August 3, 2013                 [Page 8]
Internet-Draft     Congestion Control Workshop Report       January 2013

   parallel causes irreparable harm for audio transfers.  The size of
   the initial window also impacts interactive real-time communication
   since a larger TCP initial window size (e.g., IW(10) with ten
   segments, as proposed in [17], instead of three) leads to a bigger
   burst of packets because of the initial window transmission.  Note
   that the study in [18] does not necessarily lead to the same
   conclusion.  It claims that that the increased initial window size
   leads to no impact or only modest impact for buffering in the
   majority of cases.

   Cullen Jennings [19] presented measurement results showing
   interactions between RTP and TCP flows for several widely deployed
   video communication products, i.e., 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 [20] 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

2.3.  Challenges and Design Properties

   During the remaining part of the workshop the participants discussed
   challenges and identified design properties.  The discussions in this
   session started with a presentation by Jim Gettys about problems
   related to bufferbloat [21][22].  Bufferbloat is "a phenomenon in a
   packet-switched computer network whereby excess buffering of packets
   inside the network causes high latency and jitter, as well as
   reducing the overall network throughput." [23].  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.

   Packets may get buffered at various places along the end-to-end path
   including in the operating system/device drivers, customer premise

Tschofenig, et al.       Expires August 3, 2013                 [Page 9]
Internet-Draft     Congestion Control Workshop Report       January 2013

   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 the participants were still concerned that
   many equipment manufactures 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 [REF missing].

   Active queue management (AQM) aims to prevent queues from growing too
   large.  This is accomplished by the monitoring queue length and by
   informing the sender by dropping or marking packets to lower their
   transmission rate.  Random Early Detection (RED) [24] is one such AQM
   algorithm but it has not been widely deployed in routers largely
   because of challenges to configure it correctly [25].  According to
   [26], 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.  Measurement tools that allow an end user to determine the
   performance of their 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 your network performs and to
   complain to your ISP and 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 [27]
   was to develop such metrics to qualify networks it may have started
   too early.  There are, however, recent attempts to re-visit the
   measurement work and an effort by the FCC has gotten a lot of
   attention recently, see [28].

   Matt Mathis argued that the traffic of throughput-maximizing and
   delay-minimizing applications need to be in separate queues, i.e.
   that segregated queuing is applied.  Requiring segregated queues
   assumes you are sharing the network with other greedy traffic.
   Others agreed with him.  Quality of Service signaling is a way to
   deploy segregated queuing but there are several simpler alternatives,
   such as Stochastic Fair Queuing [29].  The Controlled Delay (CoDel)
   AQM algorithm [30] can also be used in combination with stochastic
   fair queuing.  Note that queue segregation is not necessary for every
   router to segregate and using it at the edge of a network where
   bottleneck links are is already sufficient.

   It was noted that current interactive voice usage over the Internet

Tschofenig, et al.       Expires August 3, 2013                [Page 10]
Internet-Draft     Congestion Control Workshop Report       January 2013

   works most of the time satisfactory.  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 your packets arrive,
   traffic does not be separated into distinct queues.  Further
   explanations were offered why many networks work surprisingly well:
   LEDBAT [31] is used for the download of software updates, voice
   traffic contributes only a small percentage of the overall Internet
   traffic, and "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 not providing a solid
   congestion control mechanism for interactive video, as it was done
   with interactive voice, could have substantial impact due to the
   potential uptake in deployment triggered by the work on RTCWeb.  He
   phrased it as "I'm worried about the approach that says 'Let us do
   the minimal' and that is what we did with voice -- nothing.  If we do
   the same with video, we're going to be in trouble.  In the class of
   space where voice is currently working, that's where I'm worried
   about video failing."  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 concluded that
   RTCWeb might be driver for the moment, but we are not only talking
   about Web browsers.

   Furthermore, Ted noted that applications will not produce media
   streams that grow to 10Mbps 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, which are already rate-limited or are we asking media
   streams that are already rate-limited to be TCP friendly?  He then
   quoted 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, is the only thing we're willing to consider
   changes in RTP control or are we willing to consider changes in TCP
   congestion control?

   This led to a discussion 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 time scale as deploying ECN [5].  Colin
   Perkins noted that while we cannot change TCP quickly, but the way

Tschofenig, et al.       Expires August 3, 2013                [Page 11]
Internet-Draft     Congestion Control Workshop Report       January 2013

   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 will produce.

   Bill Ver Steeg suggested to consider three different deployment
   environments, namely

   1.  Flows competing with flows from the host ("self-inflicted queuing

   2.  Flows competing with flows in the same sub-network (e.g. home

   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 [32])
   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 but this is considered challenging even within a single
   host.  John Leslie [33] 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
   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

Tschofenig, et al.       Expires August 3, 2013                [Page 12]
Internet-Draft     Congestion Control Workshop Report       January 2013

   if, for example, an application blast 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 how quickly?  For a phone
   call one needs to be able to say "Hello!" pretty quickly, but for
   video it may not be necessary to see the other person very quickly.
   Those 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 STUN packets [34] as part of the ICE [35] or a
   DTLS security handshake [36]) and may be used to the advantage to
   obtain a couple simple measurements.

   The group agreed that it is feasible to design a congestion control
   algorithm that work 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) Birds of a Feather ("BoF") meeting at
   IETF#84 (July 29 - August 3, 2012, Vancouver, BC, Canada) that led to
   the formation of the RMCAT working group [37].

Tschofenig, et al.       Expires August 3, 2013                [Page 13]
Internet-Draft     Congestion Control Workshop Report       January 2013

3.  Recommendations

   The participants suggested to explore two complementary solution
   tracks, as described in the two sub-sections below.

3.1.  Changes to Network Infrastructure

   Like for all other traffic on the network, better data plane
   infrastructure improves the perceived quality of the best-effort
   service the Internet provides for RTCWeb flows.  The IETF has already
   developed several technologies that would be of immediate usefulness,
   if they were 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, i.e., the ability to use different queues for different
   traffic types.  Specifically jitter/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 keep queue sizes short and therefore end-to-end
   delay low.  ECN is implemented on some end system stacks and routers,
   but frequently not enabled.  The participants expressed the
   importance to increase the deployment of ECN, even if used initially
   only in closed environments likes data centers (as with Data Center
   TCP (DCTCP) [38].

   Different mechanisms have been developed to facilitate traffic
   segregation.  Differentiated Services [39] are one possibility in
   this space.  If applications start to mark outgoing traffic
   appropriately and routers would 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 DSCPs have no defined end-to-end meaning and
   packets can be re-marked.  Quality-of-service (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 is seen as desirable.

Tschofenig, et al.       Expires August 3, 2013                [Page 14]
Internet-Draft     Congestion Control Workshop Report       January 2013

   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).  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 stream from the same host.  A single congestion
   manager within the end host or the browser could already help to
   coordinate various congestion control activities and to ensure a more
   coordinated approach between different applications, and different

   The following activities were suggested during the workshop.

   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.  The explicit mechanism involves direct congestion
      signaling usually from the congested network node, such as ECN.
      In case of implicit mechanism, packet loss events or observed
      delay increase is 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.
      Although explicit congestion signals provide the most reliable way
      for applications to react.  However, 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

Tschofenig, et al.       Expires August 3, 2013                [Page 15]
Internet-Draft     Congestion Control Workshop Report       January 2013

      control algorithms are needed due to the lack of loss indications
      caused by large buffers but when latency-based techniques were
      competing against loss-based techniques, the loss-based techniques
      got all the bandwidth.

   Algorithm Evaluation:

      The Internet consists of heterogeneous networks, which also
      includes misconfigured, and unmanaged network nodes.  Bandwidth
      and latency varies a lot.  Not only this, 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 in Focus:

      Interactive real-time voice and video data is 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 to congestion control applied to bulk transfers.  The
      latter are allows buffering of media irrespective to their content
      and more fine-grained control for a 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.

   Startup Behaviour:

      The startup media quality is very important for real-time
      interactive application and for user-perceived application
      performance.  The startup behavior of these is also different to
      other traffic.  By nature the real-time interactive communication
      applications want to provide a smooth user experience and maintain
      best media quality 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, it would be ideal to start slow
      enough to avoid excessive congestion to other flows but fast

Tschofenig, et al.       Expires August 3, 2013                [Page 16]
Internet-Draft     Congestion Control Workshop Report       January 2013

      enough to offer a good user experience.  The sweetspot, however,
      yet has to be found.

   Some workshop participants also recommended 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 [40] is already the 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.

   Finally, it was noted that ongoing IETF standardization activities
   should be supported with deployment tests, not just simulations, to
   verify the effectiveness of developed congestion control algorithms.

Tschofenig, et al.       Expires August 3, 2013                [Page 17]
Internet-Draft     Congestion Control Workshop Report       January 2013

4.  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, Alissa Cooper

Tschofenig, et al.       Expires August 3, 2013                [Page 18]
Internet-Draft     Congestion Control Workshop Report       January 2013

5.  IANA Considerations

   This memo includes no request to IANA.

Tschofenig, et al.       Expires August 3, 2013                [Page 19]
Internet-Draft     Congestion Control Workshop Report       January 2013

6.  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.

Tschofenig, et al.       Expires August 3, 2013                [Page 20]
Internet-Draft     Congestion Control Workshop Report       January 2013

7.  References

7.1.  Normative References

   [1]   Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914,
         September 2000.

   [2]   Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for
         Application Designers", BCP 145, RFC 5405, November 2008.

7.2.  Informative References

   [3]   Perkins, C. and V. Singh, "RTP Congestion Control: Circuit
         Breakers for Unicast Sessions",
         draft-ietf-avtcore-rtp-circuit-breakers-01 (work in progress),
         October 2012.

   [4]   Wikipedia, "Video compression picture types",  URL:,
         Jan. 2012.

   [5]   Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of
         Explicit Congestion Notification (ECN) to IP", RFC 3168,
         September 2001.

   [6]   Floyd, S. and J. Kempf, "IAB Concerns Regarding Congestion
         Control for Voice Traffic in the Internet", RFC 3714,
         March 2004.

   [7]   Floyd, S. and K. Fall, "Promoting the Use of End-to-End
         Congestion Control in the Internet", IEEE/ACM Transactions on
         Networking, URL:,
         Aug 1999.

   [8]   Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP
         Friendly Rate Control (TFRC): Protocol Specification",
         RFC 5348, September 2008.

   [9]   Jacobson, V., "pathchar - a tool to infer characteristics of
         Internet paths", Presented at the Mathematical Sciences
         Research Institute, Slides available from:, April 1997.

   [10]  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.

Tschofenig, et al.       Expires August 3, 2013                [Page 21]
Internet-Draft     Congestion Control Workshop Report       January 2013

   [11]  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.

   [12]  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). ACM, New York, NY, USA, pp. 171 -
         180, URL:,
         Feb. 2011.

   [13]  Zanaty, M., "Fairness Considerations for Congestion Control",
         IAB / IRTF Workshop on Congestion Control for Interactive Real-
         Time Communication , July 2012.

   [14]  Welzl, M., Damjanovic, D., and S. Gjessing, "MulTFRC: TFRC with
         weighted fairness", draft-irtf-iccrg-multfrc-01 (work in
         progress), July 2010.

   [15]  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.

   [16]  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.

   [17]  Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, "Increasing
         TCP's Initial Window", draft-ietf-tcpm-initcwnd-07 (work in
         progress), January 2013.

   [18]  Allman, M., "Comments on Bufferbloat", In SIGCOMM Comput.
         Commun. Rev. 43, 1, pp. 30 - 37, URL:, Jan. 2013.

   [19]  Jennings, C., Nandakumar, S., and H. Phan, "Vendors Considered
         Harmfull", IAB / IRTF Workshop on Congestion Control for
         Interactive Real-Time Communication , July 2012.

   [20]  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.

   [21]  Gettys, J. and J. Gettys, "Bufferbloat: Dark Buffers in the
         Internet", IEEE Internet Computing, 15, pp. 95 - 96 , May/

Tschofenig, et al.       Expires August 3, 2013                [Page 22]
Internet-Draft     Congestion Control Workshop Report       January 2013

         June 2011.

   [22]  Gettys, J. and K. Nichols, "Bufferbloat: Dark Buffers in the
         Internet", Communications of the ACM, Vol. 55 No. 1, Pages 57 -
         65, URL:,
         Jan. 2012.

   [23]  Wikipedia, "Bufferbloat",  URL:, Jan. 2012.

   [24]  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.

   [25]  Feng, W., Shin, K., Kandlur, D., and D. Saha, "The BLUE Active
         Queue Management Algorithm", In IEEE/ACM Transactions on
         Networking, 10(4), pp. 513 - 528 , August 2002.

   [26]  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.

   [27]  IETF, "IETF IP Performance Metrics (ippm) Working Group",
         Jan. 2012.

   [28]  Schulzrinne, H., Johnston, W., and J. Miller, "Large-Scale
         Measurement of Broadband Performance: Use Cases, Architecture
         and Protocol Requirements",
         draft-schulzrinne-lmap-requirements-00 (work in progress),
         September 2012.

   [29]  McKenney, P., "Stochastic Fairness Queuing", In IEEE INFOCOM'90
         Proceedings, pp. 733 - 740 , June 1990.

   [30]  Nichols, K., "Controlled Delay Active Queue Management",
         draft-nichols-tsvwg-codel-00 (work in progress), July 2012.

   [31]  Shalunov, S., Hazel, G., Iyengar, J., and M. Kuehlewind, "Low
         Extra Delay Background Transport (LEDBAT)", RFC 6817,
         December 2012.

   [32]  Welzl, M., "One control to rule them all", IAB / IRTF Workshop
         on Congestion Control for Interactive Real-Time Communication ,
         July 2012.

Tschofenig, et al.       Expires August 3, 2013                [Page 23]
Internet-Draft     Congestion Control Workshop Report       January 2013

   [33]  Leslie, J., "There is No Magic Transport Wand", IAB / IRTF
         Workshop on Congestion Control for Interactive Real-Time
         Communication , July 2012.

   [34]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
         - Simple Traversal of User Datagram Protocol (UDP) Through
         Network Address Translators (NATs)", RFC 3489, March 2003.

   [35]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
         Protocol for Network Address Translator (NAT) Traversal for
         Offer/Answer Protocols", RFC 5245, April 2010.

   [36]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
         Security Version 1.2", RFC 6347, January 2012.

   [37]  IETF, "IETF RTP Media Congestion Avoidance Techniques (rmcat)
         Working Group", Jan. 2012.

   [38]  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, URL:, Aug. 2010.

   [39]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
         Weiss, "An Architecture for Differentiated Services", RFC 2475,
         December 1998.

   [40]  Belshe, M., Peon, R., Thomson, M., and A. Melnikov, "Hypertext
         Transfer Protocol version 2.0", draft-ietf-httpbis-http2-01
         (work in progress), January 2013.

   [41]  Mathis, M., "Position paper on CC for Interactive RT", IAB /
         IRTF Workshop on Congestion Control for Interactive Real-Time
         Communication , July 2012.

Tschofenig, et al.       Expires August 3, 2013                [Page 24]
Internet-Draft     Congestion Control Workshop Report       January 2013

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.

Tschofenig, et al.       Expires August 3, 2013                [Page 25]
Internet-Draft     Congestion Control Workshop Report       January 2013

Appendix B.  Workshop Material

   o  Main Workshop Page:

   o  Position Papers:

   o  Slides:

Tschofenig, et al.       Expires August 3, 2013                [Page 26]
Internet-Draft     Congestion Control Workshop Report       January 2013

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

   4.   "Improving the Interactive Real-Time Video Communication with
        Network Provided Congestion Notification" by ANM Zaheduzzaman
        Sarker, 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

   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

   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

   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

Tschofenig, et al.       Expires August 3, 2013                [Page 27]
Internet-Draft     Congestion Control Workshop Report       January 2013

   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

   21.  "Timely Detection of Lost Packets" by Ali C. Begen

   22.  "Congestion Control Considerations for Data Channels" by Michael

   23.  "Position paper on CC for Interactive RT" by Matt Mathis

   24.  "Overall Considerations for Congestion Control" by M. Zanaty, B.
        VerSteeg, B. Christensen, D. Benham, A. 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

   28.  "Congestion Control for Interactive Real-Time Flows on Today's
        Internet" by Keith Winstein, Anirudh Sivaraman, and Hari

   29.  "Congestion Control Principles for CoAP" by Carsten Bormann,
        Klaus Hartke

   30.  "Erasure Coding and Congestion Control for Interactive Real-Time
        Communication" by Pierre-Ugo Tournoux, Tuan Tran Thai, Emmanuel
        Lochin, Jerome Lacan, 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

Tschofenig, et al.       Expires August 3, 2013                [Page 28]
Internet-Draft     Congestion Control Workshop Report       January 2013

   33.  "Deployment Considerations for Congestion Control in Real-Time
        Interactive Media Systems" by Jari Arkko

Tschofenig, et al.       Expires August 3, 2013                [Page 29]
Internet-Draft     Congestion Control Workshop Report       January 2013

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

Tschofenig, et al.       Expires August 3, 2013                [Page 30]
Internet-Draft     Congestion Control Workshop Report       January 2013

   o  Mo Zanaty

   o  Jin Li

   o  Dave Thaler

   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

Tschofenig, et al.       Expires August 3, 2013                [Page 31]
Internet-Draft     Congestion Control Workshop Report       January 2013

   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.       Expires August 3, 2013                [Page 32]
Internet-Draft     Congestion Control Workshop Report       January 2013

Authors' Addresses

   Hannes Tschofenig
   Linnoitustie 6
   Espoo,   02600

   Phone: +358 (50) 4871445

   Lars Eggert
   Sonnenallee 1
   Kirchheim,   85551

   Phone: +49 151 12055791

   Zaheduzzaman Sarker
   Lulea,   SE-971 28

   Phone: +46 10 717 37 43

Tschofenig, et al.       Expires August 3, 2013                [Page 33]