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

[Michael Tuexen]

On Apr 5, 2012, at 5:21 PM, Michael Welzl wrote:

> 
> 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...
I agree with Michael here... Any documents available?

Best regards
Michael
> 
> Cheers,
> Michael
> 
> _______________________________________________
> Rtp-congestion mailing list
> Rtp-congestion at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/rtp-congestion
>