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

[Michael Welzl]

On Apr 5, 2012, at 4:03 PM, Justin Uberti wrote:

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

Oh, cool! I wasn't aware of that - is that documented somewhere? Sorry  
if I missed it! I'm a bit new to the whole forest of RTCWEB documents...

Cheers,
Michael