Re: [rtcweb] Congestion Control proposal

[Wesley Eddy <[e-mail]>]

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

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.

-- 
Wes Eddy
MTI Systems