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

[Matt Mathis]

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.

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?

Thanks,
--MM--
The best way to predict the future is to create it.  - Alan Kay