[rtcweb] data channel protocol comments and potential agenda topic

["Ejzak, Richard P (Richard)" <[e-mail]>]

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