Re: [rtcweb] TR : New Version Notification for draft-marcon-rtcweb-data-channel-management-00.txt

[Randell Jesup <[e-mail]>]

On 3/4/2013 8:27 AM, MARCON, JEROME (JEROME) wrote:
>
>> -----Message d'origine-----
>>
>>
>> "Whenever the application creates a new data channel, the
>> browser internally checks if the passed set of parameters
>> strictly matches an existing configuration, and if not
>> generates a new configuration identifier for this set. In the
>> latter case only does the browser trigger the application for
>> an SDP renegotiation."
>>
>> Wouldn't this occur on almost every channel because of label
>> values?  Or are you assuming applications won't actually use labels?
> In this first version of the proposal, the use of labels is still undefined, but (for the sale of scalability) it would for now remain a local data channel property not transmitted to the peer (should this local property be useful to something).
>
> I would appreciate some clarifications on the usefulness of labels in the context of data channels. W3C says nothing about it. Probably - if transmitted to the peer - it can assist the user consent decision. But then assuming the offer is for opening 100 data channels for file transfer (each channel with a distinct label), would the answerer's consent be asked 100 times (once per distinct label) ? Probably asking once "do you agree on some file transfers" is enough (and better). And the 'file transfer' information is carried by the subprotocol property, not the label.

The labels are for the application to differentiate between data 
channels that are using the same protocol.  For example, in a 
conference-with-central-mixer case, you might have a data channel to the 
mixer for each private conversation with another participant, plus one 
(or more) shared chats.  Each would be the same protocol, but have 
different labels.

Basically, they're there for the application to do something with, if it 
chooses.  It can totally ignore them if it wishes.  I'll note that RTFMP 
has a similar (though binary) concept.   They're a tool, and are 
particularly useful in cases where the data on the channel is an 
already-defined protocol as opposed to a new, application-specific 
protocol (where they could include the label inside their protocol).

These labels would need to be plumbed through to the recipient, not just 
local.

Another (I think already addressed) misunderstanding is that there's no 
requirement for user notification of data channels.  The reasoning is 
that a data channel is no different in user security/risk to existing 
mechanisms such as websockets, HTTPS connections - it just can go 
peer-to-peer and may have better latency charactistics (support for 
UDP-like transfers, etc).

>
>> "Data channel messages are sent as SCTP user messages,
>> preceded in the DATA chunk User Data field by two bytes
>> specifying data channel configuration identifier as well as
>> the message data framing type (textual or binary)."
>>
>> Aha.  So you've moved this into a true inband protocol with
>> data framing.  The current draft sends data messages with no
>> added framing required.
> Please explain why data framing is an issue. WebSocket protocol does this. The proposal also only reserves a unique PPID for the entire RTCWeb data channel functionality. Personally, I find it ackward to reserve a PPID for something like "plain transmission of any binary data or UTF-8 stream". It seemed to me that each PPID today registered with IANA is identifying a true self-contained protocol.

In-packet framing can be an annoyance for anything that's gatewaying an 
existing data stream into a channel.  It will work, but it means extra 
copying in both directions, and in some architectures/devices (SBCs, 
MCU's/conference servers) may complicate things, and some people have 
indicated the have (unspecified) usecases where they find gatewaying 
traffic directly onto these channels is desirable. Given there's a 
standard facility in SCTP that can be used for this (with a large 
address space), there seems to be little downside to using it.  I don't 
think we're in danger of running out of PPID's this millennium.  :-)

-- 
Randell Jesup
[e-mail]