[e2e] Reasons not to deply TCP BIC/Cubic

Sergey Gorinsky sergey.gorinsky at imdea.org
Thu Feb 2 06:16:09 PST 2012


  Arguing about which TCP version is better is mostly irrelevant because
there exists no such thing as an ideal TCP. Different applications have
different transport needs, and no single transport protocol can satisfy
all these needs at the same time.

  For me, an eye-opening illustration of this is the following work on
bulk-data transfers where the main metric is message delay (i.e., delivery
time for the entire message, rather than its individual packets or bits):

    S. Gorinsky, E. J. Friedman, S. Henderson, and C. Jechlitschek,
"Efficient Fair Algorithms for Message Communication", Simulation
Modelling Practice and Theory, 17(3), pp. 513-527, March 2009
 
    
http://fourier.networks.imdea.org/~sergey_gorinsky/pdf/Fair_Efficiency_SMPT
_2008.pdf

This paper presents algorithms allocating the whole bottleneck capacity to
one message at a time and compares them with the instantaneously fair PS
(Processor Sharing). These algorithms reduce average message delay
significantly (e.g., 2-3 times faster delivery on average) and guarantee
that no individual message experiences a larger delay than under PS. This
result could be intuitively understood through the following simple
analogy: if 10 people want to go through a 1-person door, doing so 1
person at a time is more efficient from both collective and individual
perspectives than trying to fairly squeeze all 10 people through the door
at the same time.

  The moral of the study is that short-term fairness should not be treated
as a sacred cow in TCP design. Being unfair/aggressive on short timescales
can be socially beneficial.

  Best regards,

  Sergey 

On 2/2/12 5:21 AM, "Dave Hart" <davehart at gmail.com> wrote:

>On Wed, Feb 1, 2012 at 21:24, Detlef Bosau <detlef.bosau at web.de> wrote:
>> The more I think about BIC and CUBIC, the more I ask for the appropriate
>> problem for this nice solution.
>> I'm not quite sure whether there exists a suitable problem for just more
>> aggressive probing.
>
>Hypothetical:  "I am sharing throughput with others via a network I
>don't control.  I am greedy and want all the throughput I can get,
>fairness and inefficiency be damned."
>
>Perhaps I'm missing something, or less gracious than I should be, but
>I've always assumed this is the motivation for Linux using more
>aggressive TCP replacements.
>
>Cheers,
>Dave Hart




More information about the end2end-interest mailing list