GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7295

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7295.txt · Last modified: 2014/07/04 01:18 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki