<br><br><div class="gmail_quote">On Tue, Apr 10, 2012 at 4:02 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 7:51 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 12:10 PM, Harald Alvestrand<br></div><div class="im">
<<a href="mailto:harald@alvestrand.no" target="_blank">harald@alvestrand.no</a> <mailto:<a href="mailto:harald@alvestrand.no" target="_blank">harald@alvestrand.no</a>>> wrote:<br>
<br>
Just to summarize what I currently understand about LEDBAT as<br>
compared to the scenario that RTCWEB envisions.....<br>
<br>
- RTCWEB assumes a set of media streams, possibly supplemented by a<br>
set of data streams carrying data with real-time requirements.<br>
LEDBAT assumes that there is some amount of data that needs<br>
transferring, and that it's appropriate to delay data if congestion<br>
occurs.<br>
<br>
- RTCWEB wants to make sure delay is low as long as it's not<br>
fighting with TCP, and wants its "fair share" when competing with<br>
TCP. LEDBAT wants to back off when encountering TCP, and uses low<br>
delay as a signal of "no competition is occuring"; it doesn't care<br>
about the specific delay.<br>
<br>
<br>
I don't think it's clear that an RTCWEB flow at all times want to<br>
compete with a TCP flow to get its fair share. For instance I can<br>
imagine that a user may find that a delay of 1-2 seconds caused by the<br>
TCP flow makes the experience too bad, and that it's better to leave<br>
more bandwidth for TCP so that the TCP transfer will finish more<br>
quickly. Depends on the amount of buffer bloat, the length of the TCP<br>
flow, user preference, etc.<br>
</div></blockquote>
<br>
1-2 seconds is effectively unusable.<br>
<br>
When we compete with a (saturating) TCP flow, there are a few options:<br>
<br>
1) reduce bandwidth and hope the TCP flow won't take it all (not all TCP flows can sustain infinite bandwidth, and the TCP flow may have bottlenecks or RTT-based limits that stop it from taking everything) or that the TCP flow will use the bandwidth to end faster.<br>
<br>
2) reduce bandwidth and hope the TCP flow may not take the extra bandwidth fast enough to force the queues too deep - we reduce bandwidth and cause the queues to drain, and TCP will keep adding to its bandwidth - but at a certain rate depending on RTT/etc. We may be able to keep the queues low as we give up bandwidth in chunks, though eventually we will be driven down to our base. If we're lucky the TCP flow will (as per 1) hit another limit, or will end (not unusual for web browsing!). This really is a variant of #1.<br>
<br>
3) reduce bandwidth, but allow queues to rise to a degree (say 100-200ms, perhaps an adaptive amount). This may allow an AQM or short-queue router to cause losses to the TCP flow(s) and cause them to back off. This could be a secondary measure after initial bandwidth reductions.<br>
<br>
4) switch to pure loss-based, which means letting queue depths rise to the point of loss. Cx-TCP uses this (see recent (Nov? Dec?) ToN article referenced in my rtcweb Interim presentation from the end of Jan/early Feb). In some cases this will result in seconds of delay.<br>
<br>
There might be some possible dynamic tricks, though they may not result in a reasonable experience, such as allowing or forcing a spike in queue depths to get TCP to back off a lot, then reducing bandwidth a lot to let them drain while TCP starts to ramp back up. Eventually TCP will saturate again and force queues depths to rise, requiring you to repeat the behavior. This will cause periodic bursts of delay or loss which will be annoying, and also may lead to poor overall link utilization (though it's an attempt to get a fair share most of the time for the delay-based protocol). I doubt that overall this is practical.<div class="im">
<br>
<br></div></blockquote><div><br></div><div>I agree that those are all possible actions.</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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- RTCWEB's RTP streams consists of unidirectional streams with<br>
(currently) fairly infrequent feedback messages. LEDBAT assumes an<br>
acknowledgement stream with nearly the same packet intervals as the<br>
forward stream.<br>
<br>
My conclusion: When discussing behaviour of specific models, we can<br>
learn from LEDBAT's experiences and the scenarios it was tested in,<br>
but the design goals of LEDBAT do not resemble the design goals for<br>
congestion control in the RTCWEB scenario, and we should not expect<br>
specific properties of the implementation to fit.<br>
<br>
<br>
I agree.<br>
</blockquote>
<br></div>
As do I. Also, I *REALLY* worry about the interaction of LEDBAT flows and rtcweb flows... If it targets 100ms queuing delay as the "I'm out of the way of TCP" level, that could seriously negatively impact us (and general VoIP as well, but even more so us, since we'll again get driven into the ground trying to keep the queues drained. It may take longer, but LEDBAT flows tend to be 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 there will be since LEDBAT has a non-0 queuing target - it may "poison the waters" for any delay-based algorithm that wants to target a lower number.</blockquote>
<div><br></div><div>Yes, having two algorithms with different delay targets compete should be approximately the same thing as having a delay-based algorithm compete with a loss-based algorithm, although the effects seen may be more or less bad depending on how close the targets are. To be clear, our draft (draft-alvestrand-rtcweb-congestion) has a 0 delay target, which means that it will always let the queues drain before increasing the rate. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Randell Jesup<br>
<a href="mailto:randell-ietf@jesup.org" target="_blank">randell-ietf@jesup.org</a></font></span><div class="HOEnZb"><div class="h5"><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>