Internet Engineering Task Force                                 M. Welzl
Internet-Draft                                        University of Oslo
Intended status: Informational                                    D. Ros
Expires: April 12, 2011                                 Telecom Bretagne
                                                         October 9, 2010

         A Survey of Lower-than-Best-Effort Transport Protocols


   This document provides a survey of transport protocols which are
   designed to have a smaller bandwidth and/or delay impact on standard
   TCP than standard TCP itself when they share a bottleneck with it.
   Such protocols could be used for low-priority "background" traffic,
   as they provide what is sometimes called a "less than" (or "lower
   than") best-effort service.

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 April 12, 2011.

Copyright Notice

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

Welzl & Ros              Expires April 12, 2011                 [Page 1]

Internet-Draft            LBE Transport Survey              October 2010

   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Delay-based transport protocols  . . . . . . . . . . . . . . .  3
     2.1.  Accuracy of delay-based congestion predictors  . . . . . .  6
     2.2.  Delay-based congestion control = LBE?  . . . . . . . . . .  7
   3.  Non-delay-based transport protocols  . . . . . . . . . . . . .  7
   4.  Application layer approaches . . . . . . . . . . . . . . . . .  8
   5.  Orthogonal work  . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

Welzl & Ros              Expires April 12, 2011                 [Page 2]

Internet-Draft            LBE Transport Survey              October 2010

1.  Introduction

   This document presents a brief survey of proposals to attain a Less
   than Best Effort (LBE) service without help from routers.  We loosely
   define a LBE service as a service which results in smaller bandwidth
   and/or delay impact on standard TCP than standard TCP itself when
   sharing a bottleneck with it.  We refer to systems that provide this
   service as Less than Best Effort (LBE) systems.  Generally, LBE
   behavior can be achieved by reacting to queue growth earlier than
   standard TCP would, or by changing the congestion avoidance behavior
   of TCP without utilizing any additional implicit feedback.  Some
   mechanisms achieve a LBE behavior at the application layer, e.g. by
   changing the receiver window of standard TCP, and there is also a
   substantial amount of work that is related to the LBE concept but not
   presenting a solution that can be installed in end hosts or expected
   to work over the Internet.  According to this classification,
   solutions have been categorized in this document as delay-based
   transport protocols, non-delay-based transport protocols, application
   layer approaches and orthogonal work.

2.  Delay-based transport protocols

   It is wrong to generally equate "little impact on standard TCP" with
   "small sending rate".  Unless the sender's maximum window is limited
   for some reason, and in the absence of ECN support, standard TCP will
   normally increase its rate until a queue overflows, causing one or
   more packets to be dropped and the rate to be reduced.  A protocol
   which stops increasing the rate before this event happens can, in
   principle, achieve a better performance than standard TCP.  In the
   absence of any other traffic, this is even true for TCP itself when
   its maximum send window is limited to the bandwidth*round-trip time
   (RTT) product.

   TCP Vegas [Bra+94] is one of the first protocols that was known to
   have a smaller sending rate than standard TCP when both protocols
   share a bottleneck [Kur+00] -- yet it was designed to achieve more,
   not less throughput than standard TCP.  Indeed, when it is the only
   protocol on the bottleneck, the throughput of TCP Vegas is greater
   than the throughput of standard TCP.  Depending on the bottleneck
   queue length, TCP Vegas itself can be starved by standard TCP flows.
   This can be remedied to some degree by the RED Active Queue
   Management mechanism [RFC2309].

   The congestion avoidance behavior is the protocol's most important
   feature in terms of historical relevance as well as relevance in the
   context of this document (it has been shown that other elements of
   the protocol can sometimes play a greater role for its overall

Welzl & Ros              Expires April 12, 2011                 [Page 3]

Internet-Draft            LBE Transport Survey              October 2010

   behavior [Hen+00]).  In Congestion Avoidance, once per RTT, TCP Vegas
   calculates the expected throughput as WindowSize / BaseRTT, where
   WindowSize is the current congestion window and BaseRTT is the
   minimum of all measured RTTs.  The expected throughput is then
   compared with the actual (measured) throughput.  If the actual
   throughput is smaller than the expected throughput minus a threshold
   beta, this is taken as a sign of congestion, causing the protocol to
   linearly decrease its rate.  If the actual throughput is greater than
   the expected throughput minus a threshold alpha (with alpha < beta),
   this is taken as a sign that the network is underutilized, causing
   the protocol to linearly increase its rate.

   TCP Vegas has been analyzed extensively.  One of the most prominent
   properties of TCP Vegas is its fairness between multiple flows of the
   same kind, which does not penalize flows with large propagation
   delays in the same way as standard TCP.  While it was not the first
   protocol that uses delay as a congestion indication, its predecessors
   (which can be found in [Bra+94]) are not discussed here because of
   the historical "landmark" role that TCP Vegas has taken in the

   Transport protocols which were designed to be non-intrusive include
   TCP-LP [Kuz+06] and TCP Nice [Ven+02].  Using a simple analytical
   model, the authors of [Kuz+06] illustrate the feasibility of this
   endeavor by showing that, due to the non-linear relationship between
   throughput and RTT, it is possible to remain transparent to standard
   TCP even when the flows under consideration have a larger RTT than
   standard TCP flows.

   TCP Nice [Ven+02] follows the same basic approach as TCP Vegas but
   improves upon it in some aspects.  Because of its moderate linear-
   decrease congestion response, TCP Vegas can affect standard TCP
   despite its ability to detect congestion early.  TCP Nice removes
   this issue by halving the congestion window (at most once per RTT,
   like standard TCP) instead of linearly reducing it.  To avoid being
   too conservative, this is only done if a fixed predefined fraction of
   delay-based incipient congestion signals appears within one RTT.
   Otherwise, TCP Nice falls back to the congestion avoidance rules of
   TCP Vegas if no packet was lost or standard TCP if a packet was lost.
   One more feature of TCP Nice is its ability to support a congestion
   window of less than one packet, by clocking out single packets over
   more than one RTT.  With ns-2 simulations and real-life experiments
   using a Linux implementation, the authors of [Ven+02] show that TCP
   Nice achieves its goal of efficiently utilizing spare capacity while
   being non-intrusive to standard TCP.

   Other than TCP Vegas and TCP Nice, TCP-LP uses only the one-way delay
   (OWD) instead of the RTT as an indicator of incipient congestion.

Welzl & Ros              Expires April 12, 2011                 [Page 4]

Internet-Draft            LBE Transport Survey              October 2010

   This is done to avoid reacting to delay fluctuations that are caused
   by reverse cross-traffic.  Using the TCP Timestamps option [RFC1323],
   the OWD is determined as the difference between the receiver's
   Timestamp value in the ACK and the original Timestamp value that the
   receiver copied into the ACK.  While the result of this subtraction
   can only precisely represent the OWD if clocks are synchronized, its
   absolute value is of no concern to TCP-LP and hence clock
   synchronization is unnecessary.  Using a constant smoothing
   parameter, TCP-LP calculates an Exponentially Weighted Moving Average
   (EWMA) of the measured OWD and checks whether the result exceeds a
   threshold within the range of the minimum and maximum OWD that was
   seen during the connections's lifetime; if it does, this condition is
   interpreted as an "early congestion indication".  The minimum and
   maximum OWD values are initialized during the slow-start phase.

   Regarding its reaction to an early congestion indication, TCP-LP
   tries to strike a middle ground between the overly conservative
   choice of immediately setting the congestion window to one packet and
   the presumably too aggressive choice of halving the congestion window
   like standard TCP.  It does so by halving the window at first in
   response to an early congestion indication, then initializing an
   "interference time-out timer", and maintaining the window size until
   this timer fires.  If another early congestion indication appeared
   during this "interference phase", the window is then set to 1;
   otherwise, the window is maintained and TCP-LP continues to increase
   it the standard Additive-Increase fashion.  This method ensures that
   it takes at least two RTTs for a TCP-LP flow to decrease its window
   to 1, and, like standard TCP, TCP-LP reacts to congestion at most
   once per RTT.

   With ns-2 simulations and real-life experiments using a Linux
   implementation, the authors of [Kuz+06] show that TCP-LP is largely
   non-intrusive to TCP traffic while at the same time enabling it to
   utilize a large portion of the excess network bandwidth, which is
   fairly shared among competing TCP-LP flows.  They also show that
   using their protocol for bulk data transfers greatly reduces file
   transfer times of competing best-effort web traffic.

   Sync-TCP [Wei+05] follows a similar approach as TCP-LP, by adapting
   its reaction to congestion according to changes in the OWD.  By
   comparing the estimated (average) forward queuing delay to the
   maximum observed delay, Sync-TCP adapts the AIMD parameters depending
   on the trend followed by the average delay over an observation
   window.  Even though the authors of [Wei+05] did not explicitely
   consider its use as an LBE protocol, Sync-TCP was designed to react
   early to incipient congestion, while grabbing available bandwidth
   more aggressively than a standard TCP in congestion-avoidance mode.

Welzl & Ros              Expires April 12, 2011                 [Page 5]

Internet-Draft            LBE Transport Survey              October 2010

   Delay-based congestion control is also at the basis of proposals
   aiming at adapting TCP's congestion avoidance to very high-speed
   networks.  Some of these proposals [Tan+06][Sri+08][Liu+08] are
   hybrid loss- and delay-based mechanisms, whereas others
   [Dev+03][Wei+06][Cha+10] are variants of Vegas based solely on

2.1.  Accuracy of delay-based congestion predictors

   The accuracy of delay-based congestion predictors has been the
   subject of a good deal of research, see e.g.  [Bia+03], [Mar+03],
   [Pra+04], [Rew+06], [McC+08].  The main result of most of these
   studies is that delays (or, more precisely, round-trip times) are, in
   general, weakly correlated with congestion.  There are several
   factors that may induce such a poor correlation:

   o  Bottleneck buffer size: in principle, a delay-based mechanism
      could be made "more than TCP friendly" _if_ buffers are "large
      enough", so that RTT fluctuations and/or deviations from the
      minimum RTT can be detected by the end-host with reasonable
      accuracy.  Otherwise, it may be hard to distinguish real delay
      variations from measurement noise.

   o  RTT measurement issues: in principle, RTT samples may suffer from
      poor resolution, due to timers which are too coarse-grained with
      respect to the scale of delay fluctuations.  Also, a flow may
      obtain a very noisy estimate of RTTs due to undersampling, under
      some circumstances (e.g., the flow rate is much lower than the
      link bandwidth).  For TCP, other potential sources of measurement
      noise include: TCP segmentation offloading (TSO) and the use of
      delayed ACKs [Hay10].

   o  Level of statistical multiplexing and RTT sampling: it may be easy
      for an individual flow to "miss" loss/queue overflow events,
      especially if the number of flows sharing a bottleneck buffer is
      significant.  This is nicely illustrated e.g. in Fig. 2 of

   o  Impact of wireless links: several mechanisms that are typical of
      wireless links, like link-layer scheduling and error recovery, may
      induce strong delay fluctuations over short time scales [Gur+04].

   Whether a delay-based protocol behaves in its intended manner (e.g.,
   it is "more than TCP friendly", or it grabs available bandwidth in a
   very aggressive manner) may therefore depend on the accuracy issues
   listed above.  Moreover, protocols like Vegas need to keep an
   estimate of the minimum ("base") delay; this makes such protocols
   highly sensitive to eventual changes in the end-to-end route during

Welzl & Ros              Expires April 12, 2011                 [Page 6]

Internet-Draft            LBE Transport Survey              October 2010

   the lifetime of the flow [Mo+99].

   TODO: incorporate [Bha+07] and any references therein that may be

2.2.  Delay-based congestion control = LBE?

   Regarding the issue of false positives/false negatives with a delay-
   based congestion detector, most studies focus on the loss of
   throughput coming from the erroneous detection of queue build-up and
   of alleviation of congestion.  Arguably, for a LBE transport protocol
   it's better to err on the "more-than-TCP-friendly side", that is, to
   always yield to _perceived_ congestion whether it is "real" or not;
   however, failure to detect congestion (due to one of the above
   accuracy problems) would result in behavior that is not LBE.  For
   instance, consider the case in which the bottleneck buffer is small,
   so that the contribution of queueing delay at the bottleneck to the
   global end-to-end delay is small.  In such a case, a flow using a
   delay-based mechanism might end up consuming a good deal of bandwidth
   with respect to a competing standard TCP flow, unless it also
   incorporates a suitable reaction to loss.

   Consider also the case in which the bottleneck link is already (very)
   congested.  In such a scenario, delay variations may be quite small,
   hence, it may be very difficult to tell an empty queue from a
   heavily-loaded queue, in terms of delay fluctuation.  Therefore, a
   newly-arriving delay-based flow may start sending faster when there
   is already heavy congestion, eventually driving away loss-based flows

3.  Non-delay-based transport protocols

   4CP [Liu+07], which stands for "Competitive and Considerate
   Congestion Control", is a protocol which provides a LBE service by
   changing the window control rules of standard TCP.  A "virtual
   window" is maintained, which, during a so-called "bad congestion
   phase" is reduced to less than a predefined minimum value of the
   actual congestion window.  The congestion window is only increased
   again once the virtual window exceeds this minimum, and in this way
   the virtual window controls the duration during which the sender
   transmits with a fixed minimum rate.  The 4CP congestion avoidance
   algorithm allows for setting a target average window and avoids
   starvation of "background" flows while bounding the impact on
   "foreground" flows.  Its performance was evaluated in ns-2
   simulations and in real-life experiments with a kernel-level
   implementation in Microsoft Windows Vista.

Welzl & Ros              Expires April 12, 2011                 [Page 7]

Internet-Draft            LBE Transport Survey              October 2010

   Some work was done on applying weights to congestion control
   mechanisms, allowing a flow to be as aggressive as a number of
   parallel TCP flows at the same time.  This is usually motivated by
   the fact that users may want to assign different priorities to
   different flows.  The first, and best known, such protocol is MulTCP
   [Cro+98], which emulates N TCPs in a rather simple fashion.  Improved
   versions of the parallel-TCP idea are presented in [Hac+04] and
   [Hac+08], and there is also a variant where only one feedback loop is
   applied to control a larger traffic aggregate by the name of Probe-
   Aided (PA-)MulTCP [Kuo+08].  Another protocol, CP [Ott+04], applies
   the same concept to the TFRC protocol [RFC5348] in order to provide
   such fairness differentiation for multimedia flows.

   The general assumption underlying all of the above work is that these
   protocols are "N-TCP-friendly", i.e. they are as TCP-friendly as N
   TCPs, where N is a positive (and possibly natural) number which is
   greater than or equal to 1.  The MulTFRC [Dam+09] protocol, another
   extension of TFRC for multiple flows, is however able to support
   values between 0 and 1, making it applicable as a mechanism for a LBE
   service.  Since it does not react to delay like the mechanisms above
   but adjusts its rate like TFRC, it can probably be expected to be
   more aggressive than mechanisms such as TCP Nice or TCP-LP.  This
   also means that MulTFRC is less likely to be prone to starvation, as
   its aggression is tunable at a fine granularity even when N is
   between 0 and 1.

4.  Application layer approaches

   A simplistic, application-level approach to a background transport
   service may just consist in scheduling automated transfers at times
   when the network is lightly loaded, as described in e.g.  [Dyk+02].
   An issue with such a technique is that it may not necessarily be
   appropriate to applications like peer-to-peer file transfer, since
   the notion of an "off-peak hour" is not meaningful when end-hosts may
   be located anywhere in the world.

   TCP's built-in flow control can be used as a means to achieve a low-
   priority transport service.  For instance, the mechanism described in
   [Spr+00] controls the bandwidth by letting the receiver intelligently
   manipulate the receiver window of standard TCP.  This is done because
   the authors assume a client-server setting where the receiver's
   access link is typically the bottleneck.  The scheme incorporates a
   delay-based calculation of the expected queue length at the
   bottleneck, which is quite similar to the calculation in the above
   delay based protocols, e.g.  TCP Vegas.  Using a Linux
   implementation, where TCP flows are classified according to their
   application's needs, it is shown that a significant improvement in

Welzl & Ros              Expires April 12, 2011                 [Page 8]

Internet-Draft            LBE Transport Survey              October 2010

   packet latency can be attained over an unmodified system while
   maintaining good link utilization.

   A similar method is employed by Mehra et al.  [Meh+03], where both
   the advertised receiver window and the delay in sending ACK messages
   are dynamically adapted to attain a given rate.  As in [Spr+00],
   Mehra et al. assume that the bottleneck is located at the receiver's
   access link.  However, the latter also propose a bandwidth-sharing
   system, allowing to control the bandwidth allocated to different
   flows, as well as to allot a minimum rate to some flows.

   Receiver window tuning is also done in [Key+04], where choosing the
   right value for the window is phrased as an optimization problem.  On
   this basis, two algorithms are presented, binary search -- which is
   faster than the other one at achieving a good operation point but
   fluctuates -- and stochastic optimization, which does not fluctuate
   but converges slower than binary search.  These algorithms merely use
   the previous receiver window and the amount of data received during
   the previous control interval as input.  According to [Key+04], the
   encouraging simulation results suggest that such an application level
   mechanism can work almost as well as a transport layer scheme like

   Another way of dealing with non-interactive flows, like e.g. web
   prefetching, is to rate-limit the transfer of such bursty traffic
   [Cro+98b].  Note that one of the techniques used in [Cro+98b] is,
   precisely, to have the downloading application adapt the TCP receiver
   window, so as to reduce the data rate to the minimum needed.

   The so-called Background Intelligent Transfer Service (BITS) [BITS],
   implemented in several versions of Microsoft Windows, uses a system
   of application-layer priority levels for file-transfer jobs, together
   with monitoring of bandwidth usage of the network interface (or, in
   more recent versions, of the network gateway connected to the end-
   host), so that low-priority transfers give way to both high-priority
   (foreground) transfers and traffic from interactive applications.

5.  Orthogonal work

   Various suggestions have been published for realizing a LBE service
   by influencing the way packets are treated in routers.  One example
   is the Persistent Class Based Queuing (P-CBQ) scheme presented in
   [Car+01], which is a variant of Class Based Queuing (CBQ) with per-
   flow accounting.  RFC 3662 [RFC3662] defines a DiffServ per-domain
   behavior called "Lower Effort".  Similar Lower-Effort PDBs have been
   tested and deployed, at least in research networks [Cho+03], [QBSS].

Welzl & Ros              Expires April 12, 2011                 [Page 9]

Internet-Draft            LBE Transport Survey              October 2010

   Harp [Kok+04] realizes a LBE service by dissipating background
   traffic to less-utilized paths of the network.  This is achieved
   without changing routers by using edge nodes as relays.  According to
   the authors, these edge nodes should be gateways of organizations in
   order to align their scheme with usage incentives, but the technical
   solution would also work if Harp was only deployed in end hosts.  It
   detects impending congestion by looking at delay, similar to TCP Nice
   [Ven+02], and manages to improve utilization and fairness over pure
   single-path solutions.

   An entirely different approach is taken in [Egg+05]: here, the
   priority of a flow is reduced via a generic idletime scheduling
   strategy in a host's operating system.  While results presented in
   this paper show that the new scheduler can effectively shield regular
   tasks from low-priority ones (e.g.  TCP from greedy UDP) with only a
   minor performance impact, it is an underlying assumption that all
   involved end hosts would use the idletime scheduler.  In other words,
   it is not the focus of this work to protect a standard TCP flow which
   originates from any host where the presented scheduling scheme may
   not be implemented.

   In [Ven+08], Venkataraman et al. propose a transport-layer approach
   to leverage an existing, network-layer LBE service based on priority
   queueing.  The transport protocol, which they call PLT (Priority-
   Layer Transport), splits a layer-4 connection into two flows, a high-
   priority one and a low-priority one.  The high-priority flow is sent
   over the higher-priority queueing class (in principle, offering a
   best-effort service) using an AIMD, TCP-like congestion control
   mechanism.  The low-priority flow, which is mapped to the LBE class,
   uses a non TCP-friendly congestion control algorithm.  The goal of
   PLT is thus to maximize its aggregate throughput by exploiting unused
   capacity in an aggressive way, while protecting standard TCP flows
   carried by the best-effort class.  [Ott+03] proposes simple changes
   to the AIMD parameters of TCP for use over a network-layer LBE
   service, so that such "filler" traffic may aggressively consume
   unused bandwidth.  Note that [Ven+08] also considers a mechanism for
   detecting the lack of priority queueing in the network, so that the
   non-TCP friendly flow may be inhibited.  The PLT receiver monitors
   the loss rate of both flows; if the high-priority flow starts seeing
   losses while the low-priority one does not experience 100% loss, this
   is taken as an indication of the absence of strict priority queueing.

   Another technique is that used by protocols like NF-TCP [Aru+10b],
   where a bandwidth-estimation module integrated into the transport
   protocol allows to rapidly take advantage of free capacity.  NF-TCP
   combines this with an early congestion detection based on Explicit
   Congestion Notification (ECN) [RFC3168] and RED [RFC2309]; when
   congestion starts building up, appropriate tuning of a RED queue

Welzl & Ros              Expires April 12, 2011                [Page 10]

Internet-Draft            LBE Transport Survey              October 2010

   allows to mark low-priority (i.e., NF-TCP) packets with a much higher
   probability than high-priority (i.e., standard TCP) packets, so low-
   priority flows yield up bandwidth before standard TCP flows.

6.  Acknowledgements

   The authors would like to thank Dragana Damjanovic, Melissa Chavez,
   Yinxia Zhao and Mayutan Arumaithurai for reference pointers.

7.  IANA Considerations

   This memo includes no request to IANA.

8.  Security Considerations

   This document introduces no new security considerations.

9.  Informative References

   [Aru+10b]  Arumaithurai, M., Fu, X., and K. Ramakrishnan, "NF-TCP: A
              Network Friendly TCP Variant for Background Delay-
              Insensitive Applications", Technical Report No. IFI-TB-
              2010-05,  Institute of Computer Science, University of
              Goettingen, Germany, September 2010, <http://

   [BITS]     Microsoft, "Windows Background Intelligent Transfer

   [Bha+07]   Bhandarkar, S., Reddy, A., Zhang, Y., and D. Loguinov,
              "Emulating AQM from end hosts", Proceedings of ACM
              SIGCOMM 2007, 2007.

   [Bia+03]   Biaz, S. and N. Vaidya, "Is the round-trip time correlated
              with the number of packets in flight?", Proceedings of the
              3rd ACM SIGCOMM conference on Internet measurement (IMC
              '03) , pages 273-278, 2003.

   [Bra+94]   Brakmo, L., O'Malley, S., and L. Peterson, "TCP Vegas: New
              techniques for congestion detection and avoidance",
              Proceedings of SIGCOMM '94, pages 24-35, August 1994.

Welzl & Ros              Expires April 12, 2011                [Page 11]

Internet-Draft            LBE Transport Survey              October 2010

   [Car+01]   Carlberg, K., Gevros, P., and J. Crowcroft, "Lower than
              best effort: a design and implementation", Workshop on
              Data communication in Latin America and the
              Caribbean 2001, San Jose, Costa Rica, Pages: 244 - 265,

   [Cha+10]   Chan, Y., Lin, C., Chan, C., and C. Ho, "CODE TCP: A
              competitive delay-based TCP", Computer Communications ,
              33(9):1013-1029, June 2010.

   [Cho+03]   Chown, T., Ferrari, T., Leinen, S., Sabatino, R., Simar,
              N., and S. Venaas, "Less than Best Effort: Application
              Scenarios and Experimental Results", Proceedings of
              QoS-IP , pages 131-144, February 2003.

   [Cro+98]   Crowcroft, J. and P. Oechslin, "Differentiated end-to-end
              Internet services using a weighted proportional fair
              sharing TCP", ACM SIGCOMM Computer Communication
              Review vol. 28, no. 3 (July 1998), pp. 53-69, 1998.

   [Cro+98b]  Crovella, M. and P. Barford, "The network effects of
              prefetching", Proceedings of Infocom 1998, April 1998.

   [Dam+09]   Damjanovic, D. and M. Welzl, "MulTFRC: Providing Weighted
              Fairness for Multimedia Applications (and others too!)",
              ACM Computer Communication Review vol. 39, no. 3 (July
              2009), 2009.

   [Dev+03]   De Vendictis, A., Baiocchi, A., and M. Bonacci, "Analysis
              and enhancement of TCP Vegas congestion control in a mixed
              TCP Vegas and TCP Reno network scenario", Performance
              Evaluation , 53(3-4):225-253, 2003.

   [Dyk+02]   Dykes, S. and K. Robbins, "Limitations and benefits of
              cooperative proxy caching", IEEE Journal on Selected Areas
              in Communications  20(7):1290-1304, September 2002.

   [Egg+05]   Eggert, L. and J. Touch, "Idletime Scheduling with
              Preemption Intervals", Proceedings of 20th ACM Symposium
              on Operating Systems Principles SOSP 2005, Brighton,
              United Kingdom, pp. 249/262, October 2005.

   [Gur+04]   Gurtov, A. and S. Floyd, "Modeling wireless links for
              transport protocols", ACM SIGCOMM Computer Communications
              Review  34(2):85-96, April 2004.

   [Hac+04]   Hacker, T., Noble, B., and B. Athey, "Improving Throughput
              and Maintaining Fairness using Parallel TCP", Proceedings

Welzl & Ros              Expires April 12, 2011                [Page 12]

Internet-Draft            LBE Transport Survey              October 2010

              of Infocom 2004, March 2004.

   [Hac+08]   Hacker, T. and P. Smith, "Stochastic TCP: A Statistical
              Approach to Congestion Avoidance", Proceedings of
              PFLDnet 2008, March 2008.

   [Hay10]    Hayes, D., "Timing enhancements to the FreeBSD kernel to
              support delay and rate based TCP mechanisms", Technical
              Report 100219A , Centre for Advanced Internet
              Architectures, Swinburne University of Technology,
              February 2010.

   [Hen+00]   Hengartner, U., Bolliger, J., and T. Gross, "TCP Vegas
              revisited", Proceedings of Infocom 2000, March 2000.

   [Key+04]   Key, P., Massoulie, L., and B. Wang, "Emulating Low-
              Priority Transport at the Application Layer: a Background
              Transfer Service", Proceedings of ACM SIGMETRICS 2004,
              January 2004.

   [Kok+04]   Kokku, R., Bohra, A., Ganguly, S., and A. Venkataramani,
              "A Multipath Background Network Architecture", Proceedings
              of Infocom 2007, May 2007.

   [Kuo+08]   Kuo, F. and X. Fu, "Probe-Aided MulTCP: an aggregate
              congestion control mechanism", ACM SIGCOMM Computer
              Communication Review vol. 38, no. 1 (January 2008), pp.
              17-28, 2008.

   [Kur+00]   Kurata, K., Hasegawa, G., and M. Murata, "Fairness
              Comparisons Between TCP Reno and TCP Vegas for Future
              Deployment of TCP Vegas", Proceedings of INET 2000,
              July 2000.

   [Kuz+06]   Kuzmanovic, A. and E. Knightly, "TCP-LP: low-priority
              service via end-point congestion control", IEEE/ACM
              Transactions on Networking (ToN)  Volume 14, Issue 4, pp.
              739-752., August 2006,

   [Liu+07]   Liu, S., Vojnovic, M., and D. Gunawardena, "Competitive
              and Considerate Congestion Control for Bulk Data
              Transfers", Proceedings of IWQoS 2007, June 2007.

   [Liu+08]   Liu, S., Basar, T., and R. Srikant, "TCP-Illinois: A loss-
              and delay-based congestion control algorithm for high-
              speed networks", Performance Evaluation , 65(6-7):417-440,

Welzl & Ros              Expires April 12, 2011                [Page 13]

Internet-Draft            LBE Transport Survey              October 2010

   [Mar+03]   Martin, J., Nilsson, A., and I. Rhee, "Delay-based
              congestion avoidance for TCP", IEEE/ACM Transactions on
              Networking , 11(3):356-369, June 2003.

   [McC+08]   McCullagh, G. and D. Leith, "Delay-based congestion
              control: Sampling and correlation issues revisited",
              Technical report , Hamilton Institute, 2008.

   [Meh+03]   Mehra, P., Zakhor, A., and C. De Vleeschouwer, "Receiver-
              Driven Bandwidth Sharing for TCP", Proceedings of
              Infocom 2003, April 2003.

   [Mo+99]    Mo, J., La, R., Anantharam, V., and J. Walrand, "Analysis
              and Comparison of TCP Reno and TCP Vegas", Proceedings of
              Infocom 1999, March 1999.

   [Ott+03]   Ott, B., Warnky, T., and V. Liberatore, "Congestion
              control for low-priority filler traffic", SPIE QoS 2003
              (Quality of Service over Next-Generation Internet), In
              Proc. SPIE, Vol. 5245, 154, Monterey (CA), USA, July 2003.

   [Ott+04]   Ott, D., Sparks, T., and K. Mayer-Patel, "Aggregate
              congestion control for distributed multimedia
              applications", Proceedings of Infocom 2004, March 2004.

   [Pra+04]   Prasad, R., Jain, M., and C. Dovrolis, "On the
              effectiveness of delay-based congestion avoidance",
              Proceedings of PFLDnet , 2004.

   [QBSS]     "QBone Scavenger Service (QBSS)", Internet2 QBone
              Initiative .

   [RFC1323]  Jacobson, V., Braden, B., and D. Borman, "TCP Extensions
              for High Performance", RFC 1323, May 1992.

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

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

   [RFC3662]  Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort
              Per-Domain Behavior (PDB) for Differentiated Services",

Welzl & Ros              Expires April 12, 2011                [Page 14]

Internet-Draft            LBE Transport Survey              October 2010

              RFC 3662, December 2003.

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

   [Rew+06]   Rewaskar, S., Kaur, J., and D. Smith, "Why don't delay-
              based congestion estimators work in the real-world?",
              Technical report TR06-001 , University of North Carolina
              at Chapel Hill, Dept. of Computer Science, January 2006.

   [Sha+05]   Shalunov, S., Dunn, L., Gu, Y., Low, S., Rhee, I., Senger,
              S., Wydrowski, B., and L. Xu, "Design Space for a Bulk
              Transport Tool", Technical Report , Internet2 Transport
              Group, May 2005.

   [Spr+00]   Spring, N., Chesire, M., Berryman, M., Sahasranaman, V.,
              Anderson, T., and B. Bershad, "Receiver based management
              of low bandwidth access links", Proceedings of
              Infocom 2000, pp. 245-254, vol.1, 2000.

   [Sri+08]   Sridharan, M., Tan, K., Bansala, D., and D. Thaler,
              "Compound TCP: A new TCP congestion control for high-speed
              and long distance networks", Internet Draft
              draft-sridharan-tcpm-ctcp , work in progress,
              November 2008.

   [Tan+06]   Tan, K., Song, J., Zhang, Q., and M. Sridharan, "A
              Compound TCP approach for high-speed and long distance
              networks", Proceedings of IEEE INFOCOM 2006, Barcelona,
              Spain, April 2008.

   [Ven+02]   Venkataramani, A., Kokku, R., and M. Dahlin, "TCP Nice: a
              mechanism for background transfers", Proceedings of
              OSDI '02, 2002.

   [Ven+08]   Venkataraman, V., Francis, P., Kodialam, M., and T.
              Lakshman, "A priority-layered approach to transport for
              high bandwidth-delay product networks", Proceedings of ACM
              CoNEXT,  Madrid, December 2008.

   [Wei+05]   Weigle, M., Jeffay, K., and F. Smith, "Delay-based early
              congestion detection and adaptation in TCP: impact on web
              performance", Computer Communications  28(8):837-850,
              May 2005.

   [Wei+06]   Wei, D., Jin, C., Low, S., and S. Hegde, "FAST TCP:
              Motivation, architecture, algorithms, performance", IEEE/

Welzl & Ros              Expires April 12, 2011                [Page 15]

Internet-Draft            LBE Transport Survey              October 2010

              ACM Transactions on Networking , 14(6):1246-1259,
              December 2006.

Authors' Addresses

   Michael Welzl
   University of Oslo
   Department of Informatics, PO Box 1080 Blindern
   N-0316 Oslo,

   Phone: +43 512 507 6110

   David Ros
   Telecom Bretagne
   Rue de la Chataigneraie, CS 17607
   35576 Cesson Sevigne cedex,

   Phone: +33 2 99 12 70 46

Welzl & Ros              Expires April 12, 2011                [Page 16]