[rtcweb] Comments on data channel related drafts

["Lijing (Jessie)" <[e-mail]>]

Hi,

Several comments on data channel related drafts.

Firstly, There are several "protocol" concepts appeared in different data channel related drafts, and it seems there is no clear statement about the relationship between these concepts.

draft-ietf-rtcweb-data-protocol has two protocol concept:

1.  The protocol byte in data channel open message defined as the protocol for the channel.

2.  SCTP payload protocol identifier (PPID)


WebRTC W3C API has one protocol concept,

3.  Protocol defined as "Subprotocol name used for this channel"


Q1: is the W3C API parameter "protocol" be the same as the protocol byte in the data channel open message?


In previous email discussion, Peter Thatcher said :

"The PPID isn't exposed to the application.  It's just used to

distinguish text/binary/control.    If an application uses different

data channels with different protocols, it should use the SID to distinguish between them, not the PPID.  In fact, even if it wanted to use the PPID, it wouldn't be able to."



Q2: if the answer of Q1 is yes. Then an application can distinguish different data channels with different protocols by the protocol byte in the data channel open message. Is my understanding right?

draft-ejzak-mmusic-data-channel-sdpneg provides a way to negotiate sub-protocol parameters out of band.

4.  Sub-protocol: The 'sub-protocol' parameter indicates which protocol the client expects to exchange via the channel.

example: a=dcmap:5000 stream=2;label="channel 2"; subprotocol="BFCP";max_retr=3

Q3: is this "subprotocol" be the same concept as the protocol byte in the data channel open message? And the W3C API "protocol" should be set as BFCP?

========================================================================

Secondly, in draft-ietf-rtcweb-data-channel-07, section 8 defines the following PPIDs
      +------------------------------------+-----------+-----------+
      | Value                              | SCTP PPID | Reference |
      +------------------------------------+-----------+-----------+
      | WebRTC String                      | 51        | [RFCXXXX] |
      | WebRTC Binary Partial (Deprecated) | 52        | [RFCXXXX] |
      | WebRTC Binary                      | 53        | [RFCXXXX] |
      | WebRTC String Partial (Deprecated) | 54        | [RFCXXXX] |
      +------------------------------------+-----------+-----------+

Q4: It is confusing what is the intention to define "WebRTC Binary Partial" and "WebRTC String Partial". I guess these two PPIDs are provided to the application in the case when application supports fragmentation of large messages. But, at the meantime, in this draft, section 6.6 also says: The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary Partial" is deprecated. Why the usage is deprecated? Does this implies that SCTP layer is responsible for fragmentation of large messages, and it is unnecessary for the upper application to implement the fragmentation of large messages?

Q5: Since PPID 52 and 54 are defined, then how can the browser know whether the data sent from the upper application layer is a part of a whole message and the SCTP PPID should be signaled as Partial 52/54, or this is a whole message and should be signaled as 51/54?

Q6: if one side wants to send two messages, and the application split the first big message to two packages, then the browser will send three SCTP packages whose PPID are 54(part of first message), 51(part of first message), 51(the whole second message) respectively. When the receiver side receives these three SCTP packages, how can the receiver side know which two SCTP packages can be assembled to get the first big message?

=========================================================================

The last question, which I have asked in previous email and have not received any response until now, so I mention this question again.

in draft-ietf-rtcweb-data-channel-07, Section 4 says:

   Req. 4:   The application SHOULD be able to provide guidance as to

             the relative priority of each data channel relative to each

             other, and relative to the media streams.  This will

             interact with the congestion control algorithms.



And in draft-ietf-rtcweb-data-protocol-03, DATA_CHANNEL_OPEN Message is defined as below
0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Message Type |  Channel Type |            Priority           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Reliability Parameter                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         Label Length          |       Protocol Length         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               /
   |                             Label                             |
   /                                                               \
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   \                                                               /
   |                            Protocol                           |
   /                                                               \

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Priority: 2 bytes (integer)
      The priority of the channel as described in
      [I-D.ietf-rtcweb-data-channel].  The higher the number, the lower
      the priority.



Q7: It seems that for now there is no W3C API parameters to set the priority of data channel. I wonder whether the priority of the data channel is open to the application or is only decided by the browser. In other words, I want to know how the application be able to provide guidance as to the priority.



Best Regards,



Jessie