[R-C] One congestion control to bind them all!

[Justin Uberti]

On Thu, Apr 5, 2012 at 8:14 AM, Michael Welzl <michawe at ifi.uio.no> wrote:

> Dear all,
>
> First, let me apologize for giving you "Michael's view of how our
> transport should be built" in this piecemeal fashion... you're getting a
> glimpse at how gradual my brain operates  :-(    I just can't help it.
>
> I have now figured out that the best way to do transport for RTCWEB would
> involve using only ONE type of congestion control for everything (note that
> I'm not making any specific argument here about whether this is based on
> draft-alvestrand-rtcweb-**congestion or LEDBAT or whatever).
>
> Why?
>
> Simply because your goal is to keep the delay low, by avoiding queue
> growth. TCP - and also SCTP's standard congestion control - will always try
> to push up the bottleneck queue until it sees a packet loss (or ECN), and
> therefore always be detrimental. Now, that's just a fact of life that we
> have to deal with - there may be other TCP traffic sharing the same
> bottleneck, and we want to do reasonably well in competition while trying
> to minimize queuing delay. This is not an ideal situation but it's what we
> have to live with. However, what we really don't want to do is to embed a
> standard-TCP-like congestion control mechanism WITHIN RTCWEB?!
>
> If an RTCWEB user wants to have a video phone conversation and at the same
> time sends a file, if I understand it correctly, that file would be
> transferred using SCTP and its standard TCP-like congestion control. So the
> file transfer would push up the queue at the bottleneck and thereby
> increase the delay experienced by the user - the user would shoot
> her/himself in her/his foot by sending the file. You really don't want that
> to happen, I guess?
>
> I think that the correct solution to that problem is to have only one type
> of congestion control, make it (mostly) delay-based to minimize queuing
> delay, and let that congestion control dictate the total rate available to
> the RTCWEB sender. Then, let the sender schedule packets across the video-,
> audio- and file-transfer streams based on some fairness policy. This gives
> you the best possible control over fairness as an extra - it's much better
> than trying to influence how the flows compete with each other on the
> bottleneck. Well, and again it seems to me that SCTP looks ideal for that
> type of usage.
>
> Theoretically, it could perhaps be okay to use multiple different types of
> delay-based (delay-minimizing) controls in parallel, e.g. using
> draft-alvestrand-rtcweb-**congestion-01 for video / audio and LEDBAT for
> data transfer, but that just seems to make the situation more complicated
> and it would give you less control over the fairness among the streams.
>
> Curious to hear what you think  :-)    because I *know* I'm right   :-D
>
>
I think we agree - to avoid the exact problems you mention, the plan has
been to replace the SCTP CC module with a CC that is common across media
and data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/rtp-congestion/attachments/20120405/01d25a13/attachment-0001.html>