Re: [rtcweb] Comments on data channel related drafts

[Michael Tuexen <[e-mail]>]

On Feb 21, 2014, at 10:21 AM, Lijing (Jessie) <[e-mail]> wrote:

> 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?
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 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.
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
> 
> BR,
> Jessie
> -----Original Message-----
> From: Michael Tuexen [mailto:[e-mail]] 
> Sent: Friday, February 21, 2014 6:13 AM
> To: Lijing (Jessie)
> Cc: [e-mail]
> Subject: Re: [rtcweb] Comments on data channel related drafts
> 
> On Feb 19, 2014, at 12:07 PM, Lijing (Jessie) <[e-mail]> wrote:
> 
>> 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?
> 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.
>> 
>> 
>> 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."
> 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.
>> 
>> 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?
> Again: there is no protocol byte... It is a string and is is the subprotocol...
>> 
>> ======================================================================
>> ==
>> 
>> 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?
> 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 Partial 52/54, or this is a whole message and should be signaled as 51/54?
> 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), 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?
> It worked only for ordered reliable data channels. So the sequence was used. Once you got PPID 51, the message is complete.
>> 
>> ======================================================================
>> ===
>> 
>> 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.
> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> 
>