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

[Michael Welzl]

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

I think I have seen and heard about the wish to let the user  
prioritize flows, and somehow avoid that the flows would be totally  
ignorant about each other - but this is not the same as what I'm  
suggesting: a *single* congestion control instance for everything.

Now I'm not sure if I get this right:
1) Justin's statement above means that there is a plan to have one  
single SCTP CC module for everything in the "data channel", but there  
will still be different congestion control for RTP/UDP transfer =>  
then this is not what I mean, you still won't get the same efficiency  
as if you use one CC instance for *everything*, by which I really mean  
*everything*.

2) Justin's statement above means what I say here (one CC instance for  
*everything*) => then I have missed that and misunderstood the  
discussion, and just think it's good.


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

I saw that presentation, but I had interpreted it as being only about  
the SCTP data channel, which would be case 1) above. Even if you  
extend that to incorporate other streams with cross-reporting as you  
describe above, it sounds like a complicated vehicle that will, I  
think, never be as efficient as simply having a single congestion  
control instance for everything.

Cheers,
Michael