Re: [rtcweb] Open data channel issues

"Karl Stahl" <> Mon, 03 March 2014 15:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0D4061A0141 for <>; Mon, 3 Mar 2014 07:06:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.899
X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TDVLng3CekHL for <>; Mon, 3 Mar 2014 07:06:31 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B005D1A0127 for <>; Mon, 3 Mar 2014 07:06:30 -0800 (PST)
Received: from ([]) by (Telecom3 SMTP service) with ASMTP id 201403031606260796 for <>; Mon, 03 Mar 2014 16:06:26 +0100
From: Karl Stahl <>
References: <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Mon, 03 Mar 2014 16:06:22 +0100
Message-ID: <000101cf36f2$23da7a60$6b8f6f20$@stahl>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0002_01CF36FA.859EE260"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac827igaTGTVlXvJRqSyhoh73r3fLAAA/I8Q
Content-Language: sv
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 15:06:33 -0000



Från: rtcweb [] För Justin Uberti
Skickat: den 3 mars 2014 15:37
Till: Randell Jesup
Ämne: Re: [rtcweb] Open data channel issues




On Mon, Mar 3, 2014 at 5:51 AM, Randell Jesup <> wrote:

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.


In the simplest case, you could just have a medium-sized buffer of size (max expected transfer rate * worst-case poll interval); 10 MB would be plenty for almost all cases.


If you wanted to be smarter, you could start with 1MB buffer, poll every 100 ms, and then adjust the buffer size to be at least ((data sent since last poll / time since last poll) * worst-case poll interval), where worst-case poll interval, accounting for GC, is somewhere around 1 second. 


I don't think this pushes CC onto apps, it just pushes spooling onto them, which is the consequence of not having streams yet.


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

rtcweb mailing list