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

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Mon, 4 Mar 2013 16:28:12 +0000

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)

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'

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

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

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.

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.

Jerome

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> De la part de Martin Thomson
> Envoyé : lundi 18 février 2013 18:52
> À : [email-masked]
> Objet : [rtcweb] Data Channels Proposal: Now in Internet Draft Form
> 
> I think that we're actually at the point where the involved 
> parties each understand each other's positions.  Now comes 
> the time to provide everyone else with a coherent proposal 
> that they can evaluate.
> 
> http://tools.ietf.org/html/draft-thomson-rtcweb-data-00
> 
> This is intended as an alternative to the mechanisms in 
> draft-ietf-rtcweb-data-channel.  It is also intended to 
> render draft-jesup-rtcweb-data-protocol unnecessary.  That 
> is, of course, as long as it meets with the approval of the 
> working group.
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 4 Mar 2013 09:00:49 -0800

Brief answers inline.

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

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.

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

> - 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';
});

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

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

---

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Wed, 6 Mar 2013 01:20:19 +0000

Thanks. Two new comments inline.
 
Also, if you could outline the Data Channel API needed to support your proposal, that would help the understanding.

> De : Martin Thomson [mailto:[email-masked]] 
> Envoyé : lundi 4 mars 2013 18:01
> À : MARCON, JEROME (JEROME)
> Cc : [email-masked]
> Objet : Re: [rtcweb] Data Channels Proposal: Now in Internet 
> Draft Form
> 
> Brief answers inline.
> 
> > 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.
> 

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 6 Mar 2013 17:03:50 -0800

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.