Re: [rtcweb] Open data channel issues

Randell Jesup <> Mon, 03 March 2014 13:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D42B51A0194 for <>; Mon, 3 Mar 2014 05:53:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xfiA_x18hIZN for <>; Mon, 3 Mar 2014 05:53:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 443411A0175 for <>; Mon, 3 Mar 2014 05:53:12 -0800 (PST)
Received: from ([]:1788 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <>) id 1WKTIr-0001rt-8H for; Mon, 03 Mar 2014 07:53:09 -0600
Message-ID: <>
Date: Mon, 03 Mar 2014 08:51:44 -0500
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020203070104000208010204"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Subject: Re: [rtcweb] Open data channel issues
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 03 Mar 2014 13:53:14 -0000

On 3/3/2014 8:28 AM, Justin Uberti wrote:
> On Mon, Mar 3, 2014 at 3:44 AM, Randell Jesup < 
> <>> wrote:
>     On 3/3/2014 6:18 AM, Justin Uberti wrote:
>>     On Sun, Mar 2, 2014 at 6:42 PM, Randell Jesup
>>     < <>> wrote:
>>>     So I still think manual chunking seems like a reasonable thing
>>>     to support. I don't quite get the congestion control concerns;
>>>     just because there is a max chunk size doesn't mean the impl
>>>     can't buffer multiple chunks in bufferedAmount; the app could
>>>     let that fill up to a degree to avoid having to poll constantly
>>>     to prevent underrun.
>>         On a slow link this will work if the browser isn't janky.  On
>>         a fast link GC pauses and other things may cause the buffer
>>         to drain out and go idle for significant periods.
>>     Since the amount buffered is up to the app, the app can just
>>     increase the buffer size to provide enough data to cover the next
>>     second or so of transfer.
>     How does the app increase the size of the internal SCTP buffers? 
>     (And that buffer is shared by all channels, of course).
> What I meant is the app can make multiple calls to send() at a time, 
> each with a chunk, which will be buffered in the api layer and 
> increase bufferedAmount.

Aha - that explains "increase the buffer size".  Yes, that will work, 
modulo that the app will have to track the actual bandwidth by either 
monitoring how fast the bufferedAmount drains, or via a JS API to report 
bandwidth ala the bug I opened on JS interaction with congestion 
control.  I still feel this pushes some level of congestion control into 
the JS app (and done like trying to thread needles with oven mitts on - 
ok, mild exaggeration) or the app will simply ignore this issue (likely) 
and get sub-optimal performance, perhaps significantly.  So I think more 
thought would be useful here, especially at the W3/JS level.

If we have the bandwidth reporting, having the app choose a reasonable 
amount of buffering would be much easier/simpler.

Randell Jesup -- rjesup a t mozilla d o t com