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

[Harald Alvestrand <[e-mail]>]

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?

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

> 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

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
> ---------------------
> 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

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

> Jerome
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb