[R-C] LEDBAT - introductions?

[Michael Welzl]

On Apr 6, 2012, at 1:45 AM, Matt Mathis wrote:

> There is one especially useful design point to extract here.....
>
> I believe that by default ledbat has a 50mS set point.  That is, it  
> regulates its rate/window size by sensing if the one way queue time  
> seems to be above or below 50mS.
>
> Would this be acceptable for RTCweb, or would it be necessary to  
> choose some other set point?

Good question; I guess you don't want to have a set point at all and  
back off as soon as delay increases? - but that may be hard when  
trying to get some bandwidth in competition with standard TCP;  
actually, how much bandwidth you would get with any such fixed point  
(yes, including the value 0 !) would depend on the queue length at the  
bottleneck, which is not under your control. e.g., if the queue >=  
BDP, it becomes an unavoidable trade-off between acceptable delay and  
achievable bandwidth. Then, maybe the right thing would really be to  
make that a knob for the user?

Of course, if you assume that your traffic is somehow isolated, as you  
wrote in previously posted text, you don't need to worry about that;  
and your assumption, as you also wrote in a recent email, is basically  
that users would then stop running any other traffic. That would  
however mean that we might end up developing a very-low-delay system  
that simply cannot work when anything else is going on. As a user, I'd  
rather have a knob for that (and I'm not into user interfaces with  
bells and whistles, mind you  :-)   but that can be one simple, yet  
important knob).

>
> (BTW, Ledbat makes no claims about fairness, etc., just that it can  
> consume most of an otherwise under-filled network.)

In my post answering Harald's query, I mentioned this link, where  
there's a number of papers analyzing LEDBAT:
http://perso.telecom-paristech.fr/~drossi/index.php?n=Software.LEDBAT

in particular, this one identifies the "latecomer unfairness" problem  
exhibited by LEDBAT:
http://perso.telecom-paristech.fr/~drossi/paper/rossi10globecom-a.pdf

I'm not sure if this has then been fixed in the standard, but in my  
review of draft-alvestrand-rtcweb-congestion:
http://www.alvestrand.no/pipermail/rtp-congestion/2012-March/000176.html
I mentioned that I'd be concerned about problems like that. To quote  
the first paragraph of that review:

***
Today, this has been called a "strawman proposal". I agree with this  
way of looking at it. There are some quite interesting ideas there;  
however, a lot seems to appear "out of the blue", leaving the reader  
puzzled about the rationale behind some design choices. I wonder if  
these design choices are based on some academic papers out there -  
could citations help? Anyway, instead of trying to discuss the  
algorithm "in the air", it would be better to first work with some  
data: how does the mechanism really work in a real-life system? How  
does it interact with TCP? How sensitive is this mechanism to the  
typical issues raised for delay-based controls (the latecomer  
unfairness problem, behavior with very small queues, ..)? How likely  
is it for the derived rate of the mechanism to fall below the TFRC- 
function limit, under what conditions will this happen?
***

=> my point is not that LEDBAT solves all these problems - I don't  
know if it does, anyway it would have to be tuned for RTCWEB because  
it is designed to be *less aggressive* than standard TCP. My point was  
that we should consider such existing mechanisms as a basis for delay- 
sensitive schemes rather than conjuring up a totally new and entirely  
different scheme out of the blue. Note that I only mentioned LEDBAT  
because that one is undergoing IETF standardization and should  
therefore have some acceptance here ... this is by no means the only  
delay-sensitive congestion control, the literature is full of them  
(Vegas, FAST, CTCP, TCP Illinois and (a variant of) H-TCP, to name but  
a few).

One thing that makes the RTCWEB use different is the non-greedy use  
that you have described in your text - but really I don't think that  
this requires building a whole new mechanism, it may just need a  
departure from the conservative approach that was taken with TCP under  
these circumstances. So this is a "let's not be so conservative here"  
design decision, which could probably be applied as a way of adapting  
an existing controller.

Cheers,
Michael