[R-C] LEDBAT vs RTCWeb

[Randell Jesup]

On 4/10/2012 7:51 AM, Stefan Holmer wrote:
>
>
> On Tue, Apr 10, 2012 at 12:10 PM, Harald Alvestrand
> <harald at alvestrand.no <mailto:harald at alvestrand.no>> wrote:
>
>     Just to summarize what I currently understand about LEDBAT as
>     compared to the scenario that RTCWEB envisions.....
>
>     - RTCWEB assumes a set of media streams, possibly supplemented by a
>     set of data streams carrying data with real-time requirements.
>     LEDBAT assumes that there is some amount of data that needs
>     transferring, and that it's appropriate to delay data if congestion
>     occurs.
>
>     - RTCWEB wants to make sure delay is low as long as it's not
>     fighting with TCP, and wants its "fair share" when competing with
>     TCP. LEDBAT wants to back off when encountering TCP, and uses low
>     delay as a signal of "no competition is occuring"; it doesn't care
>     about the specific delay.
>
>
> I don't think it's clear that an RTCWEB flow at all times want to
> compete with a TCP flow to get its fair share. For instance I can
> imagine that a user may find that a delay of 1-2 seconds caused by the
> TCP flow makes the experience too bad, and that it's better to leave
> more bandwidth for TCP so that the TCP transfer will finish more
> quickly. Depends on the amount of buffer bloat, the length of the TCP
> flow, user preference, etc.

1-2 seconds is effectively unusable.

When we compete with a (saturating) TCP flow, there are a few options:

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.

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.

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.

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.

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.


>
>     - RTCWEB's RTP streams consists of unidirectional streams with
>     (currently) fairly infrequent feedback messages. LEDBAT assumes an
>     acknowledgement stream with nearly the same packet intervals as the
>     forward stream.
>
>     My conclusion: When discussing behaviour of specific models, we can
>     learn from LEDBAT's experiences and the scenarios it was tested in,
>     but the design goals of LEDBAT do not resemble the design goals for
>     congestion control in the RTCWEB scenario, and we should not expect
>     specific properties of the implementation to fit.
>
>
> I agree.

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.
If it targets 25ms, that's less problematic I suspect.

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.

-- 
Randell Jesup
randell-ietf at jesup.org