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

[Randell Jesup <[e-mail]>]

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

Agreed.

-- 
Randell Jesup
[e-mail]