[R-C] General thoughts about the congestion control for RTC web

[Michael Welzl]

Hi,


On Apr 5, 2012, at 8:12 PM, Matt Mathis wrote:

> I assembled the following text for possible inclusion in an
> introduction or problem statement:
> ----
> The RTC web congestion control is distinctly different from other
> congestion control problems.   The goal is to choose a codec and/or
> codec parameters that simultaneously minimize self inflicted queueing
> delay while maximizing [multi-media image/signal] quality.  In almost
> all cases the selected network operating point will be well below the
> operating point that would be chosen by any traditional throughput
> maximizing congestion control algorithm.
>
> The traditional congestion control problem is to maximize throughput
> for some "TCP-friendly" capacity allocation, and typically involves
> creating standing queues at bottlenecks.   Without AQM, TCP and other
> throughput maximizing protocols generally control against queue full.
> Even with AQM or delay sensing congestion control algorithms, these
> protocols generally strive to establish at least a small standing
> queue, because they get their self clock from queued data passing
> through the bottleneck, and the standing queue helps to smooth jitter
> in the ACKs and other phenomena that might otherwise cause idle
> (wasted) link capacity.
>
> The RTC web congestion control is explicitly designed to detect if a
> given encoding causes persistent queues, and to select a lower rate if
> so.   This is nearly guaranteed to leave some unused network capacity
> and would be considered suboptimal for a throughput maximizing
> protocol.   Thus it is unlikely that any properly functioning RTC web
> application will endanger any throughput maximizing protocol.
>
> The inverse is not at all true.  It can be anticipated that TCP and
> other throughput maximizing protocols have the potential to cause
> unacceptable queueing delays for RTC web based application, unless one
> of two strategies are implemented: the traffic is segregated into
> separate queues such that delay sensitive traffic does not get queued
> behind throughput maximizing traffic, or alternatively that the AQM is
> tuned to maintain very short queues under all conditions.   This
> latter strategy is likely to imply that the AQM creates sufficient
> losses or ECN marks where the throughput maximizing protocols can't
> fill the link, and leaves idle capacity.

Up to here, I like this - but it doesn't mention the need for a  
throughput-maximizing delay sensing congestion control mechanism for  
"data traffic", e.g. for sending files and such. In the light of my  
previous email ("one congestion control to bind them all"), this calls  
for at least two different types of congestion control, I guess. One  
would have made things easier, but I see the need for at least two  
based on what you've written.


> We assume that the RTC web traffic is somehow protected from other
> throughput maximizing traffic.  Enabling RTC web and throughput
> maximizing protocols to simultaneously meet their respective
> objectives in a single queue is beyond the scope of this work.
> ---
> Comments?   Debate?

I would remove that last paragraph. I don't think we make any such  
environmental assumptions?

Cheers,
Michael