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

[Michael Welzl]

On Apr 9, 2012, at 5:10 AM, Randell Jesup wrote:

> On 4/8/2012 10:41 PM, Justin Uberti wrote:
>>
>>
>> On Sun, Apr 8, 2012 at 1:59 PM, Michael Welzl <michawe at ifi.uio.no
>> <mailto:michawe at ifi.uio.no>> wrote:
>>
>>     > 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.
>>
>>
>> #2 is what I think we've had in mind - given that this is fairly
>> greenfield territory, we should be able to have a mechanism that can
>> handle both media and data. Said mechanism will still have to guess  
>> at
>> non-RTP/SCTP flows, of course.
>
> Correct - that was the stated goal, but thus far we don't have a  
> definitive answer about how to do so.  Note that harald's draft  
> generates available bandwidth estimates for all channels together if  
> you let it include bytes received by the SCTP connection in the  
> period in question.  This would at minimum allow the sender side to  
> decide (at the application layer) on a media/data split, and then  
> use that to enforce an upper limit for the SCTP connection.

Justin said that too (that #2 was the goal); good! Sorry for having  
misunderstood this.


> Even if we run everything in one congestion algorithm, we still need  
> to have a mechanism for splitting the bandwidth between media and  
> data channels; "normal" SCTP mechanisms would not suffice for media  
> streams (see some of Justin's recent comments on send timing for  
> examples of why).

... but it's really only a scheduling function... that can always do a  
better job than giving priorities to a CC. algorithm.


>>        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
>>        <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.
>
> Perhaps true - but efficiency isn't necessarily the primary goal  
> here; a quality experience for the user given the available  
> bandwidth is, including "appropriate" splits of data and media.  And  
> the reporting is because the application has knowledge of state we  
> can't have - for example if the 2nd channel of video is important,  
> or to decide if any video at all is important, or that when extra  
> bits are available they should go to higher resolution instead of  
> faster data transfer, or higher-quality audio, etc.  As discussed,  
> the WebRTC system will apply an automatic distribution of available  
> bandwidth according to static priorities given to it, but the app is  
> given the choice to intervene.
>
> This activity by the app should not cause significant issues for the  
> congestion control algorithm as mostly it's just redistributing the  
> pie.

Sure. I understand that this won't be easy, but again I'm sure that  
it's much easier to achieve when the thing you have to manipulate is  
just a scheduler that decides how the currently available rate has to  
be divided among application streams.

Cheers,
Michael