Re: [rtcweb] Congestion Control proposal

[Randell Jesup <[e-mail]>]

On 10/7/2011 3:02 PM, Bernard Aboba wrote:
>  > 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?

This (this proposal) is the mechanism which will tell the sender to 
adapt their codec settings (video encoder bitrate, etc).

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

Not on traditional SR/RR RTCP sub-packets, but on AVPF Feedback 
messages; either a variant of TMMBR (if we do all the bandwidth 
calculations in the client), or a message where we feed back cooked 
arrival statistics to the sender via a new Feedback message.  If we 
don't get this info from the receiver we'll fall back to classic 
RR/SR-based adaptation, which sucks.  Doable, but sucks (especially if 
you only get a report average every 5 seconds).

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

We'll definitely supply or apply defaults, and if the application 
doesn't choose we'll handle it for them.  We may have some hinting to 
guide our default adaptation (relative priorities).

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

You should read Harald's draft for the base algorithm that we'll be 
modifying to provide this.  The base algorithm is from a very good class 
of low-delay congestion control algorithms, based on bottleneck router 
bufferstate sensing:

http://www.ietf.org/id/draft-alvestrand-rtcweb-congestion-00.txt

-- 
Randell Jesup
[e-mail]