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