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

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Mon, 4 Mar 2013 18:36:04 +0000

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?

User consent
---------------------
These scalability-challenging scenarios not only raise scalability issues, but user experience issues as well. Should these be relevant in IETF (and not in W3C), which user consent is appropriate in the context of data channel setup ?

A) Assuming an initial/updating SDP offer declaring one 'chat' channel and 100 'file transfer' channels, each with a distinct label. The user consent will be:
* 1-line: "open data channels [for this time only | anytime during this session] for any usage/subprotocol"
* 2-line: "open data channels [for this time only | anytime during this session] for usage/subprotocol: (1) chat (2) file transfer"
* 101-line: "open data channels for this time only for usage/subprotocol.label: (1) chat.label1 (2) file transfer.label 2... (101) file transfer.label 101"

B) Assuming a data channel created in-band, with a subprotocol already negotiated
* I assume user consent is not required here ?

C) Assuming a data channel created in-band, with a subprotocol 'file transfer' never negotiated before in the SDP handshake (I think only Randell's proposal allows this)
* 1-line: "open a data channel for this time only for usage/subprotocol.label = chat.label1"  
* 1-line: "open a data channel [for this time only | anytime during this session] for usage/subprotocol = chat" 

>From these (too much detailed) cases, we can identify 3 main types of user consent for data channel setup:
U1. open any number of data channels of any type: prompted at the time of SCTP association setup 
U2. open any number of data channels of a given usage/subprotocol: prompted the first time this subprotocol is signaled to the peer (in SDP or in-band)
U3. open one data channel of a given usage/subprotocol of a given label 

Label usefulness
---------------------
I would like to understand the usefulness of data channel labels. Considering that:
- (if user consent is of type U1 or U2 described above) labels do not take part of user consent
- labels are no longer used as data channel identifiers (SCTP stream numbers are better for this, according to the 3 data channel setup proposals on the table: Randell's, Martin's and mine). 
- W3C says nothing about the use of data channel labels

Jerome

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Mar 2013 10:45:35 -0800

> Scalability-challenging scenarios

Honestly, I don't see these as being especially relevant.  Performance
under these sorts of scenarios is largely down to the browser.
Optimizing for crazy scaling cases would be a low priority.

> User consent

We've previously discussed consent for data and since this is
effectively just an optimization of existing channels, user consent
would not just be superfluous, but actually harmful.

> Label usefulness

I can see some limited use for labels.  They aren't super-effective or
necessary.  I'm sure that some people will find a use for them.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 06 Mar 2013 16:28:27 +0100

> Scalability-challenging scenarios

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?

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

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 06 Mar 2013 16:29:39 +0100

> User consent

We already have consensus that data channels don't require user consent; 
they expose no significant new security issues compared to data transfer 
via a Web server, which is already possible without user consent.

Please stop; the horse is dead.

> Label usefulness

Randell's proposal means that the channel number is not known before the 
channel is created for the normal case. (He suggests an "advanced" 
mechanism for forcing the channel number.)

Labels are useful for creating channels where the receiving application 
knows what channels to expect, but doesn't know the channel number in 
advance.

Exercise for the reader: Write an application that uses multiple data 
channels, and does not force channel numbers. Try

---

From: Randell Jesup <[email-masked]>
Date: Wed, 06 Mar 2013 11:09:42 -0500

On 3/6/2013 10:28 AM, Harald Alvestrand wrote:
>> 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?
>
> 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.
>

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.

> should make sure the API specification is clear about what happens 
> when the browser runs out of resources, and leave it at that.

Agreed.

-- 
Randell Jesup
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 06 Mar 2013 13:14:52 +0100

Exercise for the reader: Write an application that uses multiple data 
channels, and does not force channel numbers. Try it with and without 
labels.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 7 Mar 2013 12:00:24 -0800

> channels, and does not force channel numbers. Try it with and without

Yes, it's a problem.  Of course, labels are just one possible solution
to that problem.  Exposing stream ID (i.e., channel.id) achieves the
same end.  So does strict ordering.  So does in-band application
messages.