Re: [rtcweb] Data Channels Proposal: Now in Internet Draft Form

[Martin Thomson <[e-mail]>]

Brief answers inline.

On 4 March 2013 08:28, MARCON, JEROME (JEROME)
<[e-mail]> wrote:
>
> Hi Martin, thanks for your proposal. I have some comments/questions:
>
> 1. So the label locally assigned to a data channel created in-band is not transmitted to the peer ? (note that I am fine with this)

The label is a handle that is provided to the application as a
convenience.  The label is a new invention, which I'm not certain we
entirely need.  It might provide some use, but it's unclear how it
adds value over the subprotocol label.

> 2. Whereas defaulting properties like order or reliability is more or less OK, it seems more critical to default the subprotocol property. The app would have to parse the incoming user message to guess if this message is about 'chat' or 'file transfer'

Actually, in most cases, an application will only ever receive packets
that they know about beforehand.  If they need to distinguish between
chat and file transfer, they will have established conventions for
identifying those packets.  PPID is one possible convention, though I
note that most uses of SCTP I've seen don't use more than one value,
so most code ends up ignoring the PPID.

I share the same leeriness about the "protocol" label used in
thewebsocketprotocol.

> 3. Why does StreamID need to be exposed to the app ? I first thought it was to allow in-band data channel creation by a simple message sending. But then:
> - either the StreamID is a parameter of send(streamID, data) - and this breaks the alignment with WebSocket API and also the app has no handle on this data channel
> - or streamID is a parameter of createDataChannel and this seems useless as the browser is able to select a new stream number internally

Stream ID is exposed to the app because it allows the app to create
their own usage pattern.  It can create the streams it wants and
attach meaning to those numbers.  That said, stream IDs are allocated
automatically by the browser for most uses.  I'd expect that streamId
would be an optional constraint (i.e., optional in usage) on channel
creation.

There is no in-band protocol, except for the one that the application
uses.  That's important.

> 4.  Why does binaryPPID need to be exposed to the app ? The browser is expected to infer the message type from the data passed to send().

binaryPPID allows the application to generate (though not consume,
except in constrained cases) SCTP that can be consumed by any
application.  The browser doesn't "infer" anything about message
types, other than when messages use the textual PPID, in which case
they are surfaced as strings rather than the specified binary type (a
Blob or ArrayBuffer).

> 5. Finally to decrease the number of mismatching properties situations, you could simply assign a "Default=strict|loose" property to one of the data channels in the SDP.
> If set to "strict", endpoints could only create in-band data channels for which the default set of properties applies. To create other types of data channels in-band, renegotiation is required
> If set to "loose'", an endpoint receiving a user message on an closed data channel would open the data channel using these default properties. But with the risk of mismatch on subprotocol...
> This would make scalable setup scenarios like:
> - the SDP offer/answer exchange negotiates one 'chat' data channel, and one 'file transfer' Default data channel
> - later on, either endpoint creates in-band 100 data channels for file transfer -> no renegotiation needed, no property mismatch.

That's unnecessary.  If I want an application that has one "special"
channel and an arbitrary number of "normal" channels, I can do exactly
as you say and then set the properties of those spontaneously created
channels as they appear.  It doesn't require any more standardization
or browser machinery:

pc.addEventListener('datachannel', function(e) {
  var fileTransferChannel = e.channel;
  fileTransferChannel.ordered = true;
  fileTransferChannel.subprotocol = 'filetransfer';
});

> This reduces the mismatching situations, in the case where one single set of properties is mostly used at a given time in the session. But the browser (or the app) has to guess at the time of SDP negotiation which set of properties should be the default, i.e. will be used more frequently than the others later on in the session.
>
> An extended (and deterministic) approach is to restrict the role of SDP offer/answer to the negotiation of some identified set of properties (not data channels). Then data channels are created in-band by the sending of user messages on closed streams, where each user message includes a "set of properties" identifier. You may have a look at the draft I have submitted.

I didn't see a specific need for negotiating properties in such a
generic fashion.  Ultimately, each property needs some semantics when
you use it, so it seemed excessive.  In SDP at least, the extension
mechanism is well enough understood to be able to support extension
enough to allow for new properties to be defined (like ordering, which
I omitted from my draft by mistake).

That said, if you are defining an in-band protocol (a bad idea in my
opinion), the idea that properties are generic makes a great deal of
sense.  That allows applications to define what they need and allows
them to avoid unnecessary noise.

--Martin