Return-Path: X-Original-To: rtcweb@ietfa.amsl.com Delivered-To: rtcweb@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0911A0584 for ; Wed, 19 Feb 2014 03:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.748 X-Spam-Level: X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzERDBltxdPs for ; Wed, 19 Feb 2014 03:07:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 923251A0466 for ; Wed, 19 Feb 2014 03:07:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBH14002; Wed, 19 Feb 2014 11:07:48 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Feb 2014 11:07:36 +0000 Received: from SZXEMA410-HUB.china.huawei.com (10.82.72.42) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 19 Feb 2014 11:07:46 +0000 Received: from SZXEMA510-MBX.china.huawei.com ([169.254.3.206]) by SZXEMA410-HUB.china.huawei.com ([10.82.72.42]) with mapi id 14.03.0158.001; Wed, 19 Feb 2014 19:07:38 +0800 From: "Lijing (Jessie)" To: "rtcweb@ietf.org" Thread-Topic: Comments on data channel related drafts Thread-Index: AQHPLWLMOA6HXUQ9mEaoGulYw8fFAw== Date: Wed, 19 Feb 2014 11:07:38 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.171.171] Content-Type: multipart/alternative; boundary="_000_A3045C90BB645147BC99159AA47ABAC7495EAD61SZXEMA510MBXchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/ywEoujH5_np-2goUvcTUGhCoc24 Subject: [rtcweb] Comments on data channel related drafts X-BeenThere: rtcweb@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Real-Time Communication in WEB-browsers working group list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Feb 2014 11:07:56 -0000 --_000_A3045C90BB645147BC99159AA47ABAC7495EAD61SZXEMA510MBXchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Several comments on data channel related drafts. Firstly, There are several "protocol" concepts appeared in different data c= hannel related drafts, and it seems there is no clear statement about the r= elationship 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 distinguis= h 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 differe= nt 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-prot= ocol parameters out of band. 4. Sub-protocol: The 'sub-protocol' parameter indicates which protocol the= client expects to exchange via the channel. example: a=3Ddcmap:5000 stream=3D2;label=3D"channel 2"; subprotocol=3D"BFCP= ";max_retr=3D3 Q3: is this "subprotocol" be the same concept as the protocol byte in the d= ata channel open message? And the W3C API "protocol" should be set as BFCP? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Secondly, in draft-ietf-rtcweb-data-channel-07, section 8 defines the follo= wing 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 a= pplication in the case when application supports fragmentation of large mes= sages. But, at the meantime, in this draft, section 6.6 also says: The usag= e of the PPIDs "WebRTC String Partial" and "WebRTC Binary Partial" is depre= cated. Why the usage is deprecated? Does this implies that SCTP layer is re= sponsible for fragmentation of large messages, and it is unnecessary for th= e 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 messag= e 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 f= irst big message to two packages, then the browser will send three SCTP pac= kages 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 pa= ckages can be assembled to get the first big message? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The last question, which I have asked in previous email and have not receiv= ed 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 def= ined 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 priorit= y of data channel. I wonder whether the priority of the data channel is ope= n to the application or is only decided by the browser. In other words, I w= ant to know how the application be able to provide guidance as to the prior= ity. Best Regards, Jessie --_000_A3045C90BB645147BC99159AA47ABAC7495EAD61SZXEMA510MBXchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Several comments on data channe= l related drafts.

 

Firstly, There are several R= 20;protocol” concepts appeared in different data channel related draf= ts, 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 da= ta channel open message defined as the protocol for the channel.=

2= .  SCTP payload protocol i= dentifier (PPID)

=  

WebRTC W3C API has one protocol= concept,

3= .  Protocol defined as = 220;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?

 

&n= bsp;

In previous email discussion, P= eter Thatcher said :

R= 20;The PPID isn't exposed to the application.&n= bsp; It's just used to

distinguish text/binary/cont= rol.    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 y= es. Then an application can distinguish different data channels with differ= ent 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=3Ddcmap:5000 stream=3D2;label=3D"chann= el 2"; subprotocol=3D"BFCP";max_retr=3D3

 

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?

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

Secondly, in draft-ietf-rtcweb-= data-channel-07, section 8 defines the following PPIDs

      +---------= ---------------------------+-----------+-----------+=

      | Value &= nbsp;           &nbs= p;            &= nbsp;   | SCTP PPID | Reference |

      +---------= ---------------------------+-----------+-----------+=

      | WebRTC Strin= g            &n= bsp;         | 51    = ;    | [RFCXXXX] |

      | WebRTC Binar= y Partial (Deprecated) | 52        | [RF= CXXXX] |

      | WebRTC Binar= y            &n= bsp;         | 53   =      | [RFCXXXX] |

      | WebRTC Strin= g Partial (Deprecated) | 54        | [RF= CXXXX] |

      +------------------------------------+-----------+= -----------+

&n= bsp;

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 applicat= ion 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 Binar= y Partial" is deprecated. Why the usage is deprecated? Does this impli= es that SCTP layer is responsible for fragmentation of large messages, and it is unnecessary for the upper application to impl= ement the fragmentation of large messages?

&n= bsp;

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

 

Q6: if one side wants to send t= wo messages, and the application split the first big message to two package= s, 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 p= ackages can be assembled to get the first big message?

 

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 

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-ch= annel-07, Section 4 says:

   Req. 4: &n= bsp; The application SHOULD be able to provide guidance as to

    &nbs= p;        the relative priority of each = data channel relative to each

    &nbs= p;        other, and relative to the med= ia streams.  This will

    &nbs= p;        interact with the congestion c= ontrol algorithms.

 

And in draft-ietf-rtcweb-dat= a-protocol-03, DATA_CHANNEL_OPEN Message is defined as below

0       &n= bsp;           1 &nb= sp;            =      2        &= nbsp;          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

   +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

   |  Message Type |  Cha= nnel Type |          &nbs= p; Priority           |

   +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

   |     &= nbsp;           &nbs= p;  Reliability Parameter       &nb= sp;            =   |

   +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

   |     &= nbsp;   Label Length       &nb= sp;  |       Protocol Length  =        |

   +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

   \     &= nbsp;            &nb= sp;            =             &nb= sp;            =        /

   |     &= nbsp;           &nbs= p;           Label &= nbsp;           &nbs= p;            &= nbsp;  |

   /     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       \

   +-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+

   \     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       /

   |     &= nbsp;           &nbs= p;          Protocol &nbs= p;            &= nbsp;            |

   /     &= nbsp;           &nbs= p;            &= nbsp;           &nbs= p;            &= nbsp;       \

   +-+-= 3;-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-= 3;-+-+-+-+-+

Priority: 2 bytes (integer)=

      The priority of the channel as described in

      [I-D.ietf-rtcweb-data-channel].  The higher the number, the low= er

      the priority.

 

Q7: It seems that for now th= ere 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 o= nly decided by the browser. In other words, I want to know how the application be able to provide guidance as t= o the priority.

 

Best Regards,

 

Jessie

 

--_000_A3045C90BB645147BC99159AA47ABAC7495EAD61SZXEMA510MBXchi_--