[R-C] LEDBAT - introductions?

David Ros David.Ros at telecom-bretagne.eu
Tue Apr 3 15:06:20 CEST 2012


Le 3 avr. 2012 à 13:36, Harald Alvestrand a écrit :

> 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:
> 

Short summary:


> - what it is

- A delay-based congestion control mechanism.

- Designed to offer a "scavenger" / lower-than-best-effort service for bulk data.

- Sending rate (*) is adapted as a function of changes in the (forward path) one-way delay; the goal is to try to keep e2e delay below a pre-determined threshold.

(*) Well, in fact it is a window-based mechanism (like TCP's), but (different from TCP) it uses delays to drive the congestion window up and down.


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

- Currently deployed in BitTorrent clients (it's been so for a while now): http://www.bittorrent.org/beps/bep_0029.html

- It has been implemented in MacOS X too: http://opensource.apple.com/source/xnu/xnu-1699.22.81/bsd/netinet/tcp_ledbat.c . There may be other implementations, but I can't recall now.

- On the IETF side, the draft was "finished" & handed to the IESG last fall, IIRC.


> - what the core properties are?

- It tries to (a) keep small standing queues while grabbing as much bandwidth as possible, (b) be as little "intrusive" to competing TCP flows as possible, by yielding when delay increases and by being less aggressive that TCP in grabbing extra bandwidth.

- In case of loss (or ECN marks), it behaves like TCP.

HTH,

David.

PS: I have a longer summary, but I tried to keep this short as requested :-)


=================================================================
David ROS
http://www.rennes.enst-bretagne.fr/~dros/

Deadlines really start to press a week or two after they pass. -- John Perry



More information about the Rtp-congestion mailing list