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

[Michael Welzl]

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

Cheers,
Michael