[R-C] LEDBAT vs RTCWeb

[Stefan Holmer]

On Tue, Apr 10, 2012 at 12:10 PM, Harald Alvestrand <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.


>
> - 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.


>
> If I'm totally off base on any of the above, please holler.....
>
>                            Harald
>
> ______________________________**_________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/**mailman/listinfo/rtp-**congestion<http://www.alvestrand.no/mailman/listinfo/rtp-congestion>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120410/e931db1f/attachment.html>