Re: [rtcweb] Congestion Control proposal

[Bernard Aboba <[e-mail]>]

> > I can't claim to fully understand the intended architecture from the
> > description in this email, but something struck me as odd when in one
> > breath it seems like data is flowing over TCP or SCTP (layered over
> > UDP) and in another there's a separate algorithm (the Google one, or
> > some modification) running for estimating bandwidth. Those seem
> > mutually exclusive to me, unless I completely misunderstand the goal
> > (which is entirely possible).

[BA] In practice, I think the concern is largely over UDP-based traffic. 
For TCP or SCTP  traffic, the native congestion control mechanisms should
be sufficient. 

> The fallback/simplest model would be to just consider the data channels 
> under SCTP and the media channels to be separate flows, and let them 
> fight for bandwidth as normal.

[BA] There are multiple concerns here.  One was about DoS attacks, which
was about having the recipient confirm the desired bandwidth.  That's 
what Harald mentioned.

The other issue is congestion control/codec adaptation (e.g. responding
to RFC 3714 concerns).   While I understand the need for this on the
datagram channel, with respect to congestion control of RTP traffic, won't
adaptation be codec-specific?  If the codec doesn't adapt (e.g. G.711) or
does so based on RTCP feedback, how would an additional congestion
control mechanism work?  

> If we can make them work together or at least be respectful of each 
> other to avoid "fighting", that would be better.   
>

> The app may be able to help us by indicated the type of data to be transferred and the relative 
> priority of it.  (Background file transfers might stick to a small 
> percentage of the bandwidth unless bandwidth is very high; a game may 
> give priority to one stream of data over both media and other data 
> streams - it's unclear currently if we'll be able to support that, but 
> it would be nice.)

[BA] Agree. For example, if we're talking about a high-twitch game, 
you might want different behavior than for one where the datagram
channel needs more reliability.  

> Reporting changes to the application is another matter with its own
> challenges in either case, since the way the application responds will
> limit what the CC can do afterwards (without additional probing).

[BA] Yes.  


> Don't forget that we normally will have a media channel active, and if 
> video is being sent (and to a lesser extent audio, especially if we're 
> using Opus) that media channel is adaptive and can adapt upwards to find 
> the limits of bandwidth. 

[BA] Yes, it can but today that adaption is typically based on RTCP, right?

> Decisions like that are tough or impossible for webrtc to make on it's 
> own because it doesn't have the context of the application to guide it.

[BA] The problem is that handling the events correctly will also probably be
outside the capability of your average application developer.  So enabling
reasonable things to happen by default is probably a practical requirement. 

> That said, the interface and parameters and style for interacting with 
> the JS app is the thing this posting is weakest on, since I'm not 
> well-versed in the common API paradigms that JS app developers expect, 
> and I'd love proposals for how we expose these choices and information 
> to the app.

[BA] The problem in my  mind is whether we're really expecting RTCWEB
Codecs do something with the additional information provided.