Re: DataChannels API

On 9/11/2012 8:30 PM, Ejzak, Richard P (Richard) wrote:
> Hi Randell,
> 1. I do not think it is necessary to address the use of different protocols over an entire SCTP/DTLS association at this time.  This may be useful for some applications but not necessary for many others.  It would certainly need browser support and require significant new API work, which I am not advocating.
>
> 2. I do think it would be useful to allow JS negotiation of different protocols on individual DataChannels (that share a single association).  I agree that your proposal has some support for this but a few small but important things are missing.
>
> 3. It should be possible to negotiate the characteristics of a set of DataChannels using SDP so that the application (which may support multiple variants) can negotiate a particular configuration of data channels all at once (alternative 2a).  This is not important if all users download the exact same app, but is crucial in supporting a community of apps that support different (but partly overlapping) sets of capabilities.

I understand your thought, though down that road eventually lies an m= 
line for each datachannel, with full O/A negotiation of each one, and 
years of work defining how each of these protocols is layered on top of 
SCTP/DTLS DataChannels.  I may be exaggerating, but that's the logical 
conclusion of going in that direction - and to an extent, that's 
actually a superset of the problems SDP O/A was designed to solve.

Basically, the cases we have are a) the single-domain case - both apps 
are the same or are written by the same entity and can be expected to 
know how to interoperate - what the labels mean, what the data 
transferred is, etc, and b) the federated case, where the two apps 
talking to each other are from different developers. That's the only 
case where extra info defining the meaning of a DataChannel gets you much.

There was extensive discussion over months (starting 11 months ago, and 
more last winter through early spring) to arrive at this general design 
- and in fact I had advocated for a simpler solution that exposed more 
of the raw sctp interface - unidirectional channels, etc to the level 
where a protocol wasn't even needed, not even labels.  But I was 
persuaded this was a better approach, and one far more usable by the 
primary target community (Web/WebApp developers); doubly so since it 
mirrors an existing API (WebSockets).  This interchangeability with 
WebSockets is a major advantage for developers - they can take 
WebSockets code, change how they obtain the channel, and the rest of it 
should just work with DataChannel in place of WebSockets.

You'll note that WebSockets does no protocol or other definition of the 
data within the WebSocket stream.  In IETF land we tend to have 
tediously ( ;-) ) defined specs for wireline protocols since the 
assumption is based around every device having it's own implementation - 
and this would be the case for classic network elements and endpoints.  
In W3 land, the assumption is that the site controls both the servers 
and the JS code that accesses them, and "legacy" code and heterogeneous 
server/client setups are the (rare) exception and not the rule.  
WebRTC/RTCWEB straddles both worlds. Even labels goes beyond what's in 
WebSockets, but they make sense since they serve as an identifier to the 
side receiving the open what the stream is.


>
> 4. The only support you have for identifying the function of an individual channel is the "label".  There is no mechanism to reserve labels for any specific meaning across applications.  It also means that if two channels of the exact same type are needed then multiple labels need to be understood to imply the same function.  It should be possible to specify a protocol name and protocol ID for use by each channel in addition to the label.  If a proprietary application understands the label and a generic protocol identifier is sufficient, then nothing more is needed (the current proposal).  But if the app wants to both create a label for a channel and describe the function desired of the channel, it should be able to do so.  Neither of these needs to be vetted by the browser since it is for negotiation only between the JS apps.  The browser simply inserts the agreed Protocol ID into each transmitted SCTP packet.  These two items are added to the API and the SDP so that they can be negotiated between apps.

Well, the PPID's are already used by the DataChannel protocol to 
identify strings vs binary (blob/arraybuffer) data.  Thus far we've 
avoided any inline framing data; the PPIDs provide all we need.

The question is what do we really gain in practice by doing this; what 
are the real-world usecases (almost by definition federation cases), and 
what are the alternatives available within the current design.   (And 
what's the cost, in code and complexity?)

> That's all that I think is needed.  There has already been discussion of 2a, and it seems that the addition of the protocol name and id fields (which could be optional) would be small.

Adding a second protocol string (or MIME type) would be easy.  What to 
do with the string (other than make it available to the other side) is 
tougher.   The ID fields would actually have a significant negative impact.

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Wednesday, 12 September 2012 04:40:13 UTC