Re: [rtcweb] Data channel setup: scalability, user experience, labels

Randell Jesup <> Wed, 06 March 2013 16:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 63AFB21F86A6 for <>; Wed, 6 Mar 2013 08:10:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mCqyAEziX4JN for <>; Wed, 6 Mar 2013 08:10:40 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2A5E921F8644 for <>; Wed, 6 Mar 2013 08:10:34 -0800 (PST)
Received: from ([]:1896 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from <>) id 1UDGvJ-0002N9-J9 for; Wed, 06 Mar 2013 10:10:33 -0600
Message-ID: <>
Date: Wed, 06 Mar 2013 11:09:42 -0500
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:17.0) Gecko/20130215 Thunderbird/17.0.3
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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 -
Subject: Re: [rtcweb] Data channel setup: scalability, user experience, labels
X-Mailman-Version: 2.1.12
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: Wed, 06 Mar 2013 16:10:41 -0000

On 3/6/2013 10:28 AM, Harald Alvestrand wrote:
> On 03/04/2013 07:36 PM, MARCON, JEROME (JEROME) wrote:
>> I would like to get rough opinions on three data channel related topics:
>> Scalability-challenging scenarios
>> ---------------------
>> If I am not mistaken, Randell mentioned in Boston some data channel 
>> setup scenarios like: 1000 data channels opened in the same session, 
>> and possibly 100 data channels opened simultaneously (usage: file 
>> transfer). I agree it is important to keep some scalability 
>> objectives in mind when taking decisions on the data channel setup 
>> design. So what about a list of real-life scalability-challenging 
>> scenarios like:
>> 1. No SCTP association is established, and an endpoint wishes to open 
>> 100 data channels for the same usage (e.g. file transfer)
>> 2. An SCTP association is established, and an endpoint wishes to open 
>> 100 data channels for the same usage (e.g. file transfer)
>> 3. An endpoint creates and closes a data channel at a high frequency, 
>> for the same usage (probably an app misbehavior here, but...)
>> 4. ...any other?
> If you want to establish minimum performance levels that a conforming 
> application will have to support, we can certainly consider that.
> We should start by stating the minimum number of video and audio 
> channels that a conforming application will have to support, since 
> this is important for a lot of the RTCWEB use cases, and may impact 
> really scarce resources like hardware decoders.
> Supporting an extra data channel is one more control block. Perhaps a 
> few kilobytes of RAM. Buffer space (if the data channel congests) is 
> likely to take far more memory than the control blocks; should we also 
> create specifications on the minimum amount of memory available for 
> buffers?

Actually, my understanding from Michael/Randall is that the number of 
streams allowed (defined in the association) only has a few bytes of 
overhead per stream.  For each stream in use, you'd have some pretty 
lightweight protocol-wrapping and DOM objects.  The protocol-wrapping 
objects are probably a few hundred bytes each, normally.  The DOM 
objects are base-size-of-a-DOM-object plus a few typical items (event 
handlers, etc) plus the user code attached to them - which may be the 
largest per-channel overhead.

> Seriously, I see all these as quality-of-implementation issues. We 
> should make sure the API specification is clear about what happens 
> when the browser runs out of resources, and leave it at that.
> (FWIW, a rendering process in Chrome that runs out of memory, for any 
> reason, will crash. Recovery is accomplished by the user pushing 
> "reload".)


Randell Jesup