Re: [rtcweb] Congestion Control proposal

[Randell Jesup <[e-mail]>]

Comments inline

On 10/6/2011 6:47 PM, Wesley Eddy wrote:
> On 10/6/2011 11:32 AM, Randell Jesup wrote:
>>
>> Data channels:
>>
>> If we use SCTP-DTLS-UDP, we can rely on SCTP's congestion-control,
>> perhaps
>> modified to "play nice" with the media streams, and to have some
>> amount of
>> known priority relative to them. (For example, if the media streams need
>> to back off and the data streams are using a consistent amount of
>> data, it
>> could reduce the amount or rate data is sent.) We also could pre-allocate
>> some amount of bandwidth to data, and so long as it's not using it media
>> could. Note that SCTP's congestion control is supposed to be in some
>> manner pluggable, so we could modify/replace it fairly easily.
>>
>> Worst case: it acts as a separate, TCP-friendly flow we compete with.
>>
>> If we have to use TCP-over-UDP, then that will be
>> congestion-controlled for
>> each individual flow, but the non-reliable channels will need separate
>> congestion control. Simplest would be to add RTP-like timestamps to the
>> non-reliable data channels so they could pulled into the framework of the
>> RTP channels as if they were bursty RTP data.
>  >
>  > ...
>>
>> JS Interface:
>>
>> We need to tell the application about bandwidth changes, and give it the
>> option of making choices, both in the allocation of bits among the
>> various
>> streams of data, and of the actual streams themselves (adding or shutting
>> down streams, or switching modes (mono/stereo, codecs possibly, etc)). If
>> the application doesn't care to make a choice we'll do it for them. We'll
>> also want the JS application to be able to affect the congestion-control
>> status of the data channels, so it could take bits from the data channels
>> without engendering a tug-of-war and temporary over-bandwidth/buffering.
>>
>
>
> 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).

Well, I should note that the Google algorithm primarily estimates the 
buffer state of the bottleneck router, which indirectly is correlated to 
the bandwidth available at that instant.  And TCP & the default SCTP 
congestion control are loss-based AIMD algorithms, so at any point may 
have a view of available bandwidth that is inflated (due to bufferbloat) 
or too low (in recovery from a loss event(s)).  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.

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

> 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).
>
> If running TCP or SCTP, the congestion window (cwnd) and RTT should be
> sufficient to convey the available bandwidth at a point in time. If
> anything lower is reported to the app, the cwnd will never open up
> because it will be application-limited, and if anything higher is
> reported, it will build up a queue in the sender that won't be
> drained any faster than the cwnd allows.

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.  Involving the app is so that, if it wants, it 
can make more global decisions like "drop the second video stream", or 
"reduce the resolution", or "drop stereo", or "drop audio to narrowband 
to save bits for video".  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.

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.

-- 
Randell Jesup
[e-mail]