<br><br><div class="gmail_quote">On Thu, Apr 12, 2012 at 10:52 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/12/2012 4:05 AM, Stefan Holmer wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
    Right - which means someone should raise this issue about LEDBAT<br>
    ASAP. Which WG is handling it?<br>
<br>
<br>
Gave this some more thought, and the problem might not be as big as I<br>
first anticipated.<br>
<br>
When an receive-side inter-arrival time-based congestion control<br>
algorithm such as RRTCC (will refer<br></div>
to draft-alvestrand-rtcweb-__<u></u>congestion as Receive-side Real-Time<div class="im"><br>
Congestion Control, RRTCC for now. Other suggestions are welcome)<br>
compete with LEDBAT we will see a situation where the the LEDBAT flow<br>
builds up queues of 100 ms. RRTCC will observe increased inter-arrival<br>
time and react back off (although, it will probably not back off too<br>
far).<br>
</div></blockquote>
<br>
Agreed, RRTCC will back off, though probably not dramatically (depending on how aggressive the slow-start/etc of LEDBAT is).<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sooner or later I think we will reach a steady state with 100 ms<br>
delay, and that point RRTCC will act as normal.<br>
</blockquote>
<br></div>
Hmm, not sure I agree here.  Both LEDBAT and RRTCC will probe for more bandwidth, and both will see the results of the other's probes.  When either increases bandwidth use enough to cause a delay queue rise, one or both will react; and there's a question of which is more likely to react, how fast, and how will re-stabilization occur.<br>

<br>
I significantly doubt this is a stable situation; one side or the other will likely drop earlier, drop faster or stabilize and start probing again slower.  You can even see aspects of this with LEDBAT competing with itself if the target depths are close.  Since RRTCC and LEDBAT have different algorithms and time constants (I assume), it's likely that it will be unstable in a consistent direction, and one will "win".  Also they'll act differently in response to minor disruptions from other traffic.<br>

<br>
If RRTCC tries to (most of the time) stay slightly below the point where delay queues increase, this backoff will be a small amount of 'clear' bandwidth that will cause queue draining and cause LEDBAT to increase usage.  Again leading to instability (and likely LEDBAT monopolizing).<br>

<br>
It's *possible* that RRTCC will 'win', it's also definitely possible that they'll end up semi-stable where neither goes too far away from a 'fair' share.  The one thing I don't predict is stable, fair and predictable sharing of the bandwidth.  :-/</blockquote>
<div><br></div><div>I agree. Because of different averaging and trigger thresholds they will likely not end up in a stable state. It for sure seems unlikely that they will happen to fairly share the bandwidth.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the LEDBAT flow<br>
stops, RRTCC will see decreasing inter-arrival time for some time and<br>
let the queue flush before trying to grab the newly available bandwidth.<br>
</blockquote>
<br></div>
Right; I don't expect any problems there.<div class="HOEnZb"><div class="h5"><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>