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

[Randell Jesup]

On 4/5/2012 11:21 AM, 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:

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

[SNIP]

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

Justin replied:

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

If you read the early archives of this list (and discussions predating 
it on rtcweb), you'll find that goal articulated a number of times.

As one of those driving the congestion-control issue and also the data 
channel design, I've always spoken to wanting to in some manner merge 
the congestion control regimes of media and data flows, and barring that 
to at least provide feedback between them.  The last fallback to 
avoiding problems would be to partially punt the problem up to the 
application (which also knows the relative priorities of the media and 
data, and of each data flow), by reporting back to the JS application 
the current automatic distribution of available bits to the different 
streams, and allow the application to change the distribution of those 
bits to the various media and data sub-flows (but not let it increase 
the total number of bits sent directly; it could decrease it directly or 
indirectly (by removing flows, such as dropping a video stream, etc)).

We will very likely be doing that application-level reporting, and 
probably allowing the application to adjust the distribution. My 
proposal on the API for that is outstanding in the W3 side of this 
standardization effort.

I spoke more directly to this at the rtcweb Interim meeting in Febuary; 
my slides are at:
http://www.ietf.org/proceedings/interim/2012/01/31/rtcweb/slides/rtcweb-1.pdf
The relevant slides are 10-13.  While not stated on the slides, this 
discussion emanates from the goal to in some manner merge them or make 
them work together (and not fight), and this was I think re-iterated 
from the podium there.

-- 
Randell Jesup
randell-ietf at jesup.org