[R-C] LEDBAT - introductions?

[Michael Welzl]

Please, anybody, correct me - here's my personal view, in line:


On Apr 3, 2012, at 1:36 PM, Harald Alvestrand wrote:

> Query:
>
> LEDBAT has been battered about several times in recent threads.
> I don't know what it is (apart from being a WG active at http://tools.ietf.org/wg/ledbat/ 
>  ) - could anyone give a quick summary of:
>
> - what it is

it's one out of many mechanism that use delay (as a result of  
increasing queue length) as an earlier indication of congestion.  
without adding a mechanism like that "use the TCP equation as a lower  
limit" or something like that, reacting earlier than standard TCP  
makes you less aggressive - and this is what LEDBAT was designed to  
be: a mechanism that "gives way" to TCP, making itself suitable for  
background scavenger-like traffic.
RFC 6297 is a survey of other, similar mechanisms.


> - where it's at in its talk/develop/deploy/learn ycle

Regarding the state of the WG's development, the mechanism itself, it  
seems pretty much finished; details here:
http://www.ietf.org/mail-archive/web/ledbat/current/msg00557.html

Regarding experiences with the mechanism, an earlier variant of LEDBAT  
has been deployed by BitTorrent (the company, I think), and hence  
widely used and tested.
Mirja Kuehlewind, one of the authors of the draft, has a paper about  
it in her publication list:
http://www.ikr.uni-stuttgart.de/~mkuehle/XRDTabSelect=PUBS

The group of Dario Rossi has carried out a larger number of experiments:
http://perso.telecom-paristech.fr/~drossi/index.php?n=Software.LEDBAT

and someone from Apple recently posted some (positive looking) test  
results to the list.


> - what the core properties are?

It's good at giving way to TCP in its presence, and good at saturating  
a link in its absence, I think. At least that was the design goal - I  
guess the references above will tell you how good or bad it is at  
reaching its goal.

Cheers,
Michael