Re: Transport change in MS Proposal

On 8/31/2012 3:55 PM, Martin Thomson wrote:
> On 31 August 2012 09:05, Li Li <Li.NJ.Li@huawei.com> wrote:
>> So there is a 50ms delay. Would such unbound delay cause any problem in practice or do we have to force the use of worker threads?
> I cannot conceive of a WebRTC use case that would depend so heavily on
> having a <50ms delay between event and action.  Can you?
>

I can conceive of cases where it would be *highly* preferable to have a 
<50ms delay between event and action, in particular congestion control 
feedback (congestion control occurs automatically, but the app gets the 
chance to override the decisions, so long as it stays within-bounds); 
and reaction to a remote media change (channel un-mutes, resolution 
changes, etc); reaction to a datachannel message (games, remote camera 
control), etc.

And I think Li Li's point originally was that the connectivity checks 
run through JS; even if they work with a >50ms delay, such a delay will 
slow down call setup.  Running those through JS both adds overhead and 
may potentially add significant delay.

And while it's not nice, >50ms delays are quite possible in JS code.  If 
you have very large numbers of tabs in Mozilla or other things forcing 
very expensive garbage collection (or paging!), pause times can rise 
over 50ms when a GC or CC occurs (and with paging quite possibly at 
other points).  We have ongoing projects to reduce cases of eventloop 
delay ("jank", though I hate that term).

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Friday, 31 August 2012 20:26:23 UTC