<br><br><div class="gmail_quote">On Tue, Apr 10, 2012 at 4:55 PM, Randell Jesup <span dir="ltr"><<a href="mailto:randell-ietf@jesup.org">randell-ietf@jesup.org</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">On 4/10/2012 10:40 AM, Stefan Holmer wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
<br>
On Tue, Apr 10, 2012 at 4:02 PM, Randell Jesup <<a href="mailto:randell-ietf@jesup.org" target="_blank">randell-ietf@jesup.org</a><br></div><div class="im">
<mailto:<a href="mailto:randell-ietf@jesup.org" target="_blank">randell-ietf@jesup.org</a><u></u>>> wrote:<br>
    As do I.  Also, I *REALLY* worry about the interaction of LEDBAT<br>
    flows and rtcweb flows...  If it targets 100ms queuing delay as the<br>
    "I'm out of the way of TCP" level, that could seriously negatively<br>
    impact us (and general VoIP as well, but even more so us, since<br>
    we'll again get driven into the ground trying to keep the queues<br>
    drained.  It may take longer, but LEDBAT flows tend to be<br>
    close-to-infinite I would assume.<br>
    If it targets 25ms, that's less problematic I suspect.<br>
<br>
    I'm not saying I know there will be a problem here, but that I fear<br>
    there will be since LEDBAT has a non-0 queuing target - it may<br>
    "poison the waters" for any delay-based algorithm that wants to<br>
    target a lower number.<br>
<br>
<br>
Yes, having two algorithms with different delay targets compete should<br>
be approximately the same thing as having a delay-based algorithm<br>
compete with a loss-based algorithm, although the effects seen may be<br>
more or less bad depending on how close the targets are. To be clear,<br>
our draft (draft-alvestrand-rtcweb-<u></u>congestion) has a 0 delay target,<br>
which means that it will always let the queues drain before increasing<br>
the rate.<br>
</div></blockquote>
<br>
Right - which means someone should raise this issue about LEDBAT ASAP. Which WG is handling it?</blockquote><div><br></div><div>Gave this some more thought, and the problem might not be as big as I first anticipated. </div>
<div><br></div><div>When an receive-side inter-arrival time-based congestion control algorithm such as RRTCC (will refer to draft-alvestrand-rtcweb-<u></u>congestion as Receive-side Real-Time Congestion Control, RRTCC for now. Other suggestions are welcome) compete with LEDBAT we will see a situation where the the LEDBAT flow builds up queues of 100 ms. RRTCC will observe increased inter-arrival time and react back off (although, it will probably not back off too far). Sooner or later I think we will reach a steady state with 100 ms delay, and that point RRTCC will act as normal. If the LEDBAT flow stops, RRTCC will see decreasing inter-arrival time for some time and let the queue flush before trying to grab the newly available bandwidth.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<br>
-- <br>
Randell Jesup<br>
<a href="mailto:randell-ietf@jesup.org" target="_blank">randell-ietf@jesup.org</a><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>