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

[Matt Mathis]

On Thu, Apr 5, 2012 at 11:20 AM, Michael Welzl <michawe at ifi.uio.no> wrote:
>
> On Apr 5, 2012, at 8:12 PM, Matt Mathis wrote:
(snip)
>>  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.
We have several already: TCP and SCTP come to mind.  Your suggestion
of reinventing all of congestion control inside of RTC web, and moving
all existing applications over to it is perhaps excessively ambitious
and out of scope.

It has be known for a long time that throughput-maximizing delay
sensing congestion control has sharing and stability problems.   Don't
assume that since RTC web adds additional constraints, that it makes
the problem any easier.

> 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.
I agree, at least two, of which RTC web is only one.  Trying to do
throughput optimization inside of RTC web is doomed to either be
suboptimal or at crossed purposes.

>> 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.
>
>
> I would remove that last paragraph.
Well, what I wanted to say was to require QoS, but that is actually
significantly over constrained  and out of scope for the WG.  For
example with a simple SFQ controller, the RTCweb flow can find the
rate just below the onset of persistent queuing, while the bulk data
flows can find the window at the onset of loss, and both streams can
meet their own criteria for optimal.

> I don't think we make any such
> environmental assumptions?

The real point is that RTC web can not by itself prevent TCP from
causing queues at a shared bottleneck, which is explicitly TCP's goal.
   We can not fix this aspect of the problem from within the scope of
RTC web.  The best we can do is specify what assumptions we are making
about what the network should be doing to RTC  traffic, and to create
the case externally to revisit QoS and the like across the broader
Internet.

For the common home use case, user education is a sufficient
workaround: e.g. go easy on bulk application while trying to VC.  For
the enterprise case, the QoS part is easy (already done?).

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