Subject: [rtcweb] data channel protocol comments and potential agenda topic

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Thu, 19 Jul 2012 16:26:04 +0000

I have concerns about the data channel protocol as defined in draft-jesup-rtcweb-data-protocol-02.txt<http://www.ietf.org/mail-archive/web/rtcweb/current/msg04885.html> and suggest that this could be a worthwhile topic for discussion in Vancouver:

  1.  It requires many messages to be exchanged before any actual user data is sent.
  2.  It is used to set up bidirectional channels whereas a simpler convention might serve the same purpose without need of messaging (e.g., use of the same stream identifier in both directions).
  3.  No mechanism has been defined to allow the application to specify the purpose of a data channel.  In particular, no mechanism is defined to allow the application to specify the payload protocol id (other than ascii/binary).
  4.  Data channel characteristics must be specified in advance for all data carried on a data channel, whereas SCTP allows these characteristics to be controlled dynamically per chunk of transmitted data.  So new channels need to be unnecessarily created and destroyed dynamically to accommodate different characteristics.
  5.  Data channels emulate websockets and are limited by the websockets model rather than leveraging the capabilities of SCTP and specifying functionality useful for data channels.

Why do we need any data channel protocol at all?  It is just a redundant exchange of information about SCTP protocol options that can be communicated by SCTP itself with each block of data, i.e., let's turn this into an API issue and not a protocol issue.

Why don't we instead specify the API to allow the application to select the SCTP transmission characteristics (including stream id, ppid, ordered, reliable, etc.) needed per data block to be transmitted.  Alternately, the API could specify and then allow changes to these characteristics for a channel to influence the SCTP protocol options selected without initiating a data channel protocol negotiation or requiring release of the channel.

Either approach would allow new ppid's to be assigned as needed for applications to indicate the purpose of each data chunk (or sequence of data chunks) to be transmitted.  The application will be able to send data with the desired reliability characteristics immediately without waiting to exchange setup messages.  And each data channel can be repurposed dynamically without requiring signaling to release and renegotiate channel characteristics.

Richard

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 20 Jul 2012 07:34:15 +0200

One particular thread about this, the idea of "purpose":

I believe that standardizing a semantic for "purpose", and trying to 
encode that into a short integer field such as PPID, is an architectural 
mistake in protocols where the set of possible purposes is unlimited.

The protocol needs to make sure the two ends can agree on the identity 
of a channel, and that the characteristics of the channel (for instance 
unreliable/reliable, binary-transparent/non-binary-transparent, 
priority, capacity....) are known, as far as they can be. We should not 
try to encode "purpose".

Without a defined semantic for "purpose", any such field is just a 
strange encoding of more data bytes, and is better carried as part of 
the application-dependent payload.

I have opinions about the other points too, but I would like to get rid 
of the notion of encoding "purpose" in the data channel protocol.

On 07/19/2012 06:26 PM, Ejzak, Richard P (Richard) wrote:
>
> I have concerns about the data channel protocol as defined in 
> draft-jesup-rtcweb-data-protocol-02.txt 
> <http://www.ietf.org/mail-archive/web/rtcweb/current/msg04885.html> 
> and suggest that this could be a worthwhile topic for discussion in 
> Vancouver:
>
>  2. It is used to set up bidirectional channels whereas a simpler
>     convention might serve the same purpose without need of messaging
>     (e.g., use of the same stream identifier in both directions).
>  3. No mechanism has been defined to allow the application to specify
>     the purpose of a data channel.  In particular, no mechanism is
>     defined to allow the application to specify the payload protocol
>     id (other than ascii/binary).
>  4. Data channel characteristics must be specified in advance for all
>     data carried on a data channel, whereas SCTP allows these
>     characteristics to be controlled dynamically per chunk of
>     transmitted data.  So new channels need to be unnecessarily
>     created and destroyed dynamically to accommodate different
>     characteristics.
>  5. Data channels emulate websockets and are limited by the websockets
>     model rather than leveraging the capabilities of SCTP and
>     specifying functionality useful for data channels.
>
> Why do we need any data channel protocol at all?  It is just a 
> redundant exchange of information about SCTP protocol options that can 
> be communicated by SCTP itself with each block of data, i.e., let's 
> turn this into an API issue and not a protocol issue.
>
> Why don't we instead specify the API to allow the application to 
> select the SCTP transmission characteristics (including stream id, 
> ppid, ordered, reliable, etc.) needed per data block to be 
> transmitted.  Alternately, the API could specify and then allow 
> changes to these characteristics for a channel to influence the SCTP 
> protocol options selected without initiating a data channel protocol 
> negotiation or requiring release of the channel.
>
> Either approach would allow new ppid's to be assigned as needed for 
> applications to indicate the purpose of each data chunk (or sequence 
> of data chunks) to be transmitted.  The application will be able to 
> send data with the desired reliability characteristics immediately 
> without waiting to exchange setup messages.  And each data channel can 
> be repurposed dynamically without requiring signaling to release and 
> renegotiate channel characteristics.
>
> Richard
>
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Fri, 20 Jul 2012 16:10:03 +0000

I don't see any conflict between our positions, Harald.  You are arguing that we need a generic data transfer capability that can be used by any application for any purpose, which can be achieved by specifying raw data transfer, and I fully support this.  I am arguing that it would be advantageous to be able to have the option to specify an underlying protocol on a data channel so that we can develop interoperable applications.  These capabilities are not mutually exclusive.

An example might be MSRP.  If we would like to use MSRP between endpoints then we could specify that browsers need to support MSRP natively and specify a new API to access it.  Or we could allow an application to send MSRP over a data channel without impacting the browser.  This would potentially allow browsers running different communications applications to use MSRP in addition to audio and video media for communication, even if other application specific uses of data channel are not interoperable.

I'm not arguing that we should standardize MSRP over data channel - just that this approach gives us the potential to define interoperable data channel applications in the future.

It would also be a good idea to reserve a range of ppid values for proprietary use.  Then when two browsers are communicating with the same application, the application can signal the purpose behind a new block of data with the choice of proprietary ppid value.  An application might use one value to signal gaming control information and another value to signal display information.  This approach would save a typical application from exchanging signaling just to set up channels so that it can begin to use them.

---

From: Stefan Hakansson LK <[email-masked]>
Date: Sat, 21 Jul 2012 14:03:07 +0200

...
>
> Why don’t we instead specify the API to allow the application to select
> the SCTP transmission characteristics (including stream id, ppid,
> ordered, reliable, etc.) needed per data block to be transmitted.
> Alternately, the API could specify and then allow changes to these
> characteristics for a channel to influence the SCTP protocol options
> selected without initiating a data channel protocol negotiation or
> requiring release of the channel.

The current API proposal is aligned to the WebSocket API. This API is 
state-of-art for web developers, is gaining momentum, and designing 
something very different would be a mistake IMO. Anyway, the API 
discussion and design belongs in the webrtc WG.

Stefan

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Sun, 22 Jul 2012 15:08:24 +0000

I grant you that the API discussion belongs in W3C.  I don't propose to ignore the websocket API, but surely some adaptations could be considered (in W3C) if they have potential to bring advantages.

But several other points I made are unrelated to the design of the API and do belong in rtcweb.  In particular, it should be possible to create a data channel (once the SCTP association is established) without the use of a data channel control protocol and without requiring it to be pre-specified in SDP.  This is my main suggestion.  My next suggestion is to allow the application to specify the ppid value (with raw ascii or binary as options) associated with a data channel (or for each data chunk transmitted on a data channel) for the reasons I described earlier.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Stefan Hakansson LK
> Sent: Saturday, July 21, 2012 7:03 AM
> To: [email-masked]
> Subject: Re: [rtcweb] data channel protocol comments and potential agenda
> topic
> 
> > Why don't we instead specify the API to allow the application to select

---

From: Stefan Hakansson LK <[email-masked]>
Date: Sun, 22 Jul 2012 18:15:04 +0200

On 07/22/2012 05:08 PM, Ejzak, Richard P (Richard) wrote:
> I grant you that the API discussion belongs in W3C.  I don't propose
> to ignore the websocket API, but surely some adaptations could be
> considered (in W3C) if they have potential to bring advantages.
>
> But several other points I made are unrelated to the design of the
> API and do belong in rtcweb.  In particular, it should be possible to
> create a data channel (once the SCTP association is established)
> without the use of a data channel control protocol and without
> requiring it to be pre-specified in SDP.  This is my main suggestion.

I think, if doable, that is a good idea. However, I think the authors 
determined that the data channel control protocol was needed (but 
Randell/Salvatore/Michael know the details).

> My next suggestion is to allow the application to specify the ppid
> value (with raw ascii or binary as options) associated with a data
> channel (or for each data chunk transmitted on a data channel) for
> the reasons I described earlier.
>
>> -----Original Message----- From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Stefan Hakansson LK
>> Sent: Saturday, July 21, 2012 7:03 AM To: [email-masked] Subject:
>> Re: [rtcweb] data channel protocol comments and potential agenda
>> topic
>>
>> On 07/19/2012 06:26 PM, Ejzak, Richard P (Richard) wrote: ...
>>>
>>> select the SCTP transmission characteristics (including stream
>>> id, ppid, ordered, reliable, etc.) needed per data block to be
>>> changes to these characteristics for a channel to influence the
>>> SCTP protocol options selected without initiating a data channel
>>> protocol negotiation or requiring release of the channel.
>>
>> The current API proposal is aligned to the WebSocket API. This API
>> is state-of-art for web developers, is gaining momentum, and
>> designing something very different would be a mistake IMO. Anyway,
>> the API discussion and design belongs in the webrtc WG.
>>
>> Stefan
>>
>> _______________________________________________ rtcweb mailing
>> list [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________ rtcweb mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Michael Tuexen <[email-masked]>
Date: Sun, 22 Jul 2012 21:54:46 +0200

On Jul 22, 2012, at 6:15 PM, Stefan Hakansson LK wrote:

> I think, if doable, that is a good idea. However, I think the authors determined that the data channel control protocol was needed (but Randell/Salvatore/Michael know the details).
The data channel protocol is required, because:
* a channel is bi-directional and we need a mechanism to handle collisions.
* a channel has symmetric properties (like partial reliability
  policy, partial reliability parameter, priority, ordered/unordered.
  These need to be communicated.
If channels are unidirectional, things get much simpler...
Please note, that the data channel protocol is not that complex
(it is basically a three-way handshake), and it is not required
that the initiator delays sending user messages until the
handshake is completed. You can actually send the first user message
right after the first message of the handshake. They could even
get bundled on the wire. However, this requires that the JS API
allow this and I think the W3C voted against this.
>> the reasons I described earlier.
I'm not sure if I understand the suggestion completely, but it sounds
like proving most of the send/recv API from the SCTP socket API.
But again: This is an API question and needs to be handled by W3C.

Best regards
Michael

---

From: Randell Jesup <[email-masked]>
Date: Mon, 23 Jul 2012 02:51:52 -0400

> If channels are unidirectional, things get much simpler...

Correct.  My initial proposal was a much thinner layer around 
unidirectional SCTP streams, but people clearly preferred bidirectional 
channels, and in particular ones that echo the API (at the W3 level) of 
WebSockets, and I see the appeal and usefulness of that, including the 
"wait until onopen" characteristic - it makes it easy to substitute 
DataChannels for WebSockets and vice-versa (so long as the DataChannel 
doesn't *need* unreliability, and can function with a reliable 
channel).  It's an API that Web authors are comfortable with.

> allow this and I think the W3C voted against this.

Correct.  The protocol is *very* simple.  I'll note that my current 
draft indicates signaling for DataChannels that would at least be 
extendable (at the IETF/SDP level) to allowing other/alternate SCTP 
associations on the same DTLS channel, running other protocols, though 
for W3 WebRTC there would be a single one running the DataChannel protocol.

-- 
Randell Jesup
[email-masked]

---

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Mon, 23 Jul 2012 13:16:14 +0000

> for W3 WebRTC there would be a single one running the DataChannel protocol.

While this may be true from a protocol perspective, it would still require a new API to access other protocols, so they are effectively unavailable to JS.

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 25 Jul 2012 08:26:44 -0700

On 07/20/2012 09:10 AM, Ejzak, Richard P (Richard) wrote:
>
> I don't see any conflict between our positions, Harald.  You are 
> arguing that we need a generic data transfer capability that can be 
> used by any application for any purpose, which can be achieved by 
> specifying raw data transfer, and I fully support this.  I am arguing 
> that it would be advantageous to be able to have the option to specify 
> an underlying protocol on a data channel so that we can develop 
> interoperable applications.  These capabilities are not mutually 
> exclusive.
>
> An example might be MSRP.  If we would like to use MSRP between 
> endpoints then we could specify that browsers need to support MSRP 
> natively and specify a new API to access it.  Or we could allow an 
> application to send MSRP over a data channel without impacting the 
> browser.  This would potentially allow browsers running different 
> communications applications to use MSRP in addition to audio and video 
> media for communication, even if other application specific uses of 
> data channel are not interoperable.
>
Noted - we may not be in disagreement, only arguing terminology.

In my terminology, MSRP is not a purpose, it's a protocol.
It's clear to me that if applications need to standardize a way to use 
MSRP over the data channel, they need to be able to signal that this is 
what they're going to do, and have reasonable assurcance that nothing 
else is going to interfere with that purpose. There are many ways to 
achieve this purpose through signalling ("I want to do MSRP over the 
data channel named "msrp""; "OK with using "msrp"") is a typical 
signalling sequence that would accomplish the purpose), API extensions 
that can access the setup protocol in ways that the current API cannot, 
or other ways.

The discussion of that belongs, I think, in the discussion of 
standardizing MSRP over data channel, not in the discussion of the data 
channel itself.

> I'm not arguing that we should standardize MSRP over data channel -- 
> just that this approach gives us the potential to define interoperable 
> data channel applications in the future.
>
> It would also be a good idea to reserve a range of ppid values for 
> proprietary use.  Then when two browsers are communicating with the 
> same application, the application can signal the purpose behind a new 
> block of data with the choice of proprietary ppid value.  An 
> application might use one value to signal gaming control information 
> and another value to signal display information.  This approach would 
> save a typical application from exchanging signaling just to set up 
> channels so that it can begin to use them.
>
My personal opinion is that this is not a good use of PPID.

But if I understand correctly, PPID values are IANA registered. Feel 
free to make the proposal.

http://www.iana.org/assignments/sctp-parameters/sctp-parameters.xml#sctp-parameters-25