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?
(BTW, Ledbat makes no claims about fairness, etc., just that it can consume most of an otherwise under-filled network.)
Thanks,
--MM--
The best way to predict the future is to create it. - Alan Kay
On Thu, Apr 5, 2012 at 4:53 AM, Michael Welzl
<michawe@ifi.uio.no> wrote:
On Apr 4, 2012, at 12:56 PM, eemeaesarzah wrote:
On 2012-04-03 15:06, David Ros wrote:
David.
PS: I have a longer summary, but I tried to keep this short as requested :-)
I am interested on your longer summary and perhaps you can educate us about the application of LEDBAT CC algorithm to real-time media specially on this note "by yielding when delay increases and by being less aggressive that TCP in grabbing extra bandwidth".
"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."
I don't think anybody advocated using LEDBAT as it is here. But personally, I would favor "adjusting" LEDBAT by e.g. adding the "TCP equation as a lower limit" trick (which I think is neat!) and tuning its parameters over having a from-scratch design of a new delay-based mechanism. LEDBAT has already undergone some investigation, and so we'd have a more stable basis.
Cheers,
Michael