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