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

[Harald Alvestrand <[e-mail]>]

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:
>
>  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
>
>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb