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

[Martin Thomson <[e-mail]>]

I don't want to get into too deep on details.  The PPID thing is a
detail that would enable more flexibility, but that flexibility is
negotiable.  In my experience, I don't see there being much value in
negotiation/signaling "protocol" identifiers.  A priori knowledge
trumps these in most cases and WebRTC already has a strong reliance on
a priori knowledge.

On 5 March 2013 17:20, MARCON, JEROME (JEROME)
<[e-mail]> wrote:
> Thanks. Two new comments inline.
>
> Also, if you could outline the Data Channel API needed to support your proposal, that would help the understanding.
>
>> -----Message d'origine-----
>> De : Martin Thomson [mailto:[e-mail]]
>> Envoyé : lundi 4 mars 2013 18:01
>> À : MARCON, JEROME (JEROME)
>> Cc : [e-mail]
>> Objet : Re: [rtcweb] Data Channels Proposal: Now in Internet
>> Draft Form
>>
>> 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.
>
> Before the 'subprotocol' concept was ever discussed, I thought the SDP O/A should allow to negotiate the PPID to use for each channel (applied to all messages of this channel) where the PPID would be a true IANA-registered protocol defined over SCTP. Now I am fine with the negotiation of 'subprotocol' value.
>
> Randell's proposal is reserving the PPID for the per-message text/binary/control signaling, so 'subprotocol' and PPID are orthogonal. But your proposal is exposing the per-message PPID to the app (regardless of the negotiated subprotocol). So the roles of 'subprotocol' and PPID seem to potentially overlap (although semantically the PPID signals some protocol over a unidirectional SCTP stream, whereas 'subprotocol' rather signals some protocol over a bi-directional RTCWeb data channel). Maybe you have some thoughts on the potential relationships between a registered PPID and a registered subprotocol (1-1, 1-N, N-1, etc.). Example: if I write an RFC porting a file transfer protocol over RTCWeb data channel, would the RFC reserve exclusively one PPID XXX and one 'file transfer XXX' subprotocol value ?
>
> What bothers me so far in your proposal is the 'try and guess' property selection process left to the app when a message is received on a closed channel, for the 'subprotocol' property in particular. But if the subprotocol can be deterministically inferred from the incoming user message PPID, then that's a lot better.
>>
>> > 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.
>
> Like you advise, I also propose is an out-of-band SDP negotiation of sets of generic properties, with no properties carried in-band. Where I differ is that the selection of some properties (e.g. subprotocol) to apply to a channel created from an incoming message must be always (not just sometimes) deterministic.
>
>>
>> --Martin
>>