There is one especially useful design point to extract here.....<div><br></div><div>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.<div>
<br></div><div>Would this be acceptable for RTCweb, or would it be necessary to choose some other set point?</div><div><br></div><div>(BTW, Ledbat makes no claims about fairness, etc., just that it can consume most of an otherwise under-filled network.) </div>
<div><br></div><div>Thanks,<br clear="all">--MM--<br>The best way to predict the future is to create it.  - Alan Kay<br><br>
<br><br><div class="gmail_quote">On Thu, Apr 5, 2012 at 4:53 AM, Michael Welzl <span dir="ltr"><<a href="mailto:michawe@ifi.uio.no">michawe@ifi.uio.no</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
On Apr 4, 2012, at 12:56 PM, eemeaesarzah wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 2012-04-03 15:06, David Ros wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
David.<br>
<br>
PS: I have a longer summary, but I tried to keep this short as requested :-)<br>
<br>
</blockquote>
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".<br>

</blockquote>
<br></div>
to answer that bit, let me quote from my own previous email describing LEDBAT:<div class="im"><br>
<br>
"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."<br>

<br></div>
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.<br>

<br>
Cheers,<br>
Michael<div class="HOEnZb"><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
Rtp-congestion mailing list<br>
<a href="mailto:Rtp-congestion@alvestrand.no" target="_blank">Rtp-congestion@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/rtp-congestion" target="_blank">http://www.alvestrand.no/<u></u>mailman/listinfo/rtp-<u></u>congestion</a><br>
</div></div></blockquote></div><br></div></div>