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

[Michael Welzl]

On Apr 5, 2012, at 10:49 PM, Matt Mathis wrote:

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

This sounds like a misunderstanding? Or maybe it's me misunderstanding  
RTCWEB... see below:


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

My point is: if a user owns the bottleneck (typicall her/his access  
link) and doesn't use anything else but RTCWEB, we shouldn't make that  
user increase her/his own delay experienced by using e.g. RTCWEB's own  
file transfer service within the browser. That just seems stupid to  
me, as it can in fact be avoided by using a delay-sensitive control.


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

But minimal delay is an overaching goal, and creating a non-delay- 
sensitive traffic from within RTCWEB is therefore detrimental, I'd  
say. Why wouldn't it be better to mix 1) the step-wise delay-sensitive  
multimedia traffic with 2) delay-sensitive greedy traffic?


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

I see that, but I still think that saying that "we assume that the RTC  
web traffic is somehow protected" is misleading because, in reality,  
we just don't. Rather, we decide to accept that TCP will be there too,  
and considerations about the impact that this will have on RTC web and  
vice versa should be in scope (even if being strictly TCP-friendly may  
not be the goal).

All in all, I think you said all these things quite well in your text  
above that paragraph already, and I think that paragraph therefore  
doesn't add any real value. It can be a source for confusion, though.


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

Yes, but I don't think that this gets any more clear or obvious with  
that extra paragraph. Anyway, I don't have a strong opinion about this  
paragraph.

Cheers,
Michael