Subject: [rtcweb] Comments on data channel related drafts

From: "Lijing (Jessie)" <[email-masked]>
Date: Wed, 19 Feb 2014 11:07:38 +0000

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

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 20 Feb 2014 23:13:21 +0100

On Feb 19, 2014, at 12:07 PM, Lijing (Jessie) <[email-masked]> wrote:

> 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.
>  
> 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?
Correct. The DOMString protocol provided in the W3C API in negotiated in the DATA_CHANNEL_OPEN message as
the protocol field. Please note that the Protocol field in the DATA_CHANNEL_OPEN message is not a byte,
but a string.
> “The PPID isn't exposed to the application.  It's just used to
> 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.”
Data channels are identified by the SID on the wire, which corresponds to the id field in the W3C API.
The JS API has no access to the PPID.
> 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?
Not sure what the application is. The W3C API lets you distinguish the data channels, since
you have different objects for it.
> 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?
Again: there is no protocol byte... It is a string and is is the subprotocol...
> 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?
Section 6.6 explains it:

The usage of the PPIDs "WebRTC String Partial" and "WebRTC Binary Partial" is deprecated. They were used for a PPID based fragmentation and reassembly of user messages belonging to reliable and ordered data channels.
> 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 Parti…
The PPIDs 52 and 54 were intended to implement fragmentation/reassembly inside the data channel implementation.
This is how it is implemented in Firefox. There is now way to access it from the JS API.
However, the usage is deprecated and therefore you don't need to implement it.
> 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),…
It worked only for ordered reliable data channels. So the sequence was used. Once you got PPID 51, the message is complete.
You are right. The W3C API does not cover the priority yet. My understanding is
that this is missing and needs to be added. I expect that the priority is settable
via the JS API.

Best regards
Michael
>  
> Best Regards,
>  
> Jessie
>  
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Lijing (Jessie)" <[email-masked]>
Date: Fri, 21 Feb 2014 09:21:10 +0000

Hi,

Thanks a lot to Michael's interpretation, and it is really helpful.

Two more issues to be discussed:
1. I am still not quite sure what "PPID based fragmentation and reassembly " is. Does it mean SCTP performs segmentation and reassembly based on the path MTU? Or it refers to other method or protocols?

2. The priority of data channel involves two aspects, one aspect is priority of one data channel compared with priority of other data channels, and the other aspect is priority of one data channel compared with audio and video media stream tracks. If the data channel priority is settable via JS API, then the audio and video priority should also be set via JS API in a way. I think the priority should be set considering all the media types including audio, video and data channel.

BR,
Jessie
-----Original Message-----
From: Michael Tuexen [mailto:[email-masked]] 
Sent: Friday, February 21, 2014 6:13 AM
To: Lijing (Jessie)
Cc: [email-masked]
Subject: Re: [rtcweb] Comments on data channel related drafts

On Feb 19, 2014, at 12:07 PM, Lijing (Jessie) <[email-masked]> wrote:

> WebRTC W3C API has one protocol concept, 3.  Protocol defined as 
> "Subprotocol name used for this channel"
>  
Correct. The DOMString protocol provided in the W3C API in negotiated in the DATA_CHANNEL_OPEN message as the protocol field. Please note that the Protocol field in the DATA_CHANNEL_OPEN message is not a byte, but a string.
> 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?
Not sure what the application is. The W3C API lets you distinguish the data channels, since you have different objects for it.
Section 6.6 explains it:

You are right. The W3C API does not cover the priority yet. My understanding is that this is missing and needs to be added. I expect that the priority is settable via the JS API.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Fri, 21 Feb 2014 14:20:53 +0100

> 1. I am still not quite sure what "PPID based fragmentation and reassembly " is. Does it mean SCTP performs segmentation and reassembly based on the path MTU? Or it refers to other method or protoc…
SCTP performs fragmentation and reassembly as an internal mechanism. This is not related to the use of the PPID.
The "PPID based fragmentation and reassembly" is implemented on top of SCTP, but below the JS API.
So it is NOT done by the Javascript application.
When using NDATA, the PPID stuff is not necessary, since fragmentation and reassembly will be
done by SCTP without monopolizing any stream.
> 2. The priority of data channel involves two aspects, one aspect is priority of one data channel compared with priority of other data channels, and the other aspect is priority of one data channel…
I agree completely. And there is currently also no way of specifying a priority for the
media streams. However, this is an issue for W3C...

Best regards
Michael