[R-C] LEDBAT - introductions?

[Matt Mathis]

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?

(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 at 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".
>>
>
> to answer that bit, let me quote from my own previous email describing
> LEDBAT:
>
>
> "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
>
>
> ______________________________**_________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120405/baf8d216/attachment.html>