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 B82D01A00E2 for ; Fri, 21 Feb 2014 05:21:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no 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 hQQfGpMlqr9S for ; Fri, 21 Feb 2014 05:21:03 -0800 (PST) Received: from mailms.fh-muenster.de (mail.fh-muenster.de [212.201.120.190]) by ietfa.amsl.com (Postfix) with ESMTP id 751841A00B8 for ; Fri, 21 Feb 2014 05:21:02 -0800 (PST) Received: from [192.168.1.200] (p508F101C.dip0.t-ipconnect.de [80.143.16.28]) (Authenticated sender: tuexen) by mailms.fh-muenster.de (Postfix) with ESMTPSA id 8967628174D; Fri, 21 Feb 2014 14:20:54 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Michael Tuexen In-Reply-To: Date: Fri, 21 Feb 2014 14:20:53 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0693106D-71EA-4580-8CA2-E070F28E464A@lurchi.franken.de> References: <9782EE1D-7FF3-4F6B-BCDF-37C143770E96@lurchi.franken.de> To: Lijing (Jessie) X-Mailer: Apple Mail (2.1510) Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/vcEdNJf0Fb8dpNG-82idW5F2Ngo Cc: "rtcweb@ietf.org" Subject: Re: [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: Fri, 21 Feb 2014 13:21:07 -0000 On Feb 21, 2014, at 10:21 AM, Lijing (Jessie) = wrote: > Hi, >=20 > Thanks a lot to Michael's interpretation, and it is really helpful. >=20 > 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. >=20 > 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 >=20 > BR, > Jessie > -----Original Message----- > From: Michael Tuexen [mailto:Michael.Tuexen@lurchi.franken.de]=20 > Sent: Friday, February 21, 2014 6:13 AM > To: Lijing (Jessie) > Cc: rtcweb@ietf.org > Subject: Re: [rtcweb] Comments on data channel related drafts >=20 > On Feb 19, 2014, at 12:07 PM, Lijing (Jessie) = wrote: >=20 >> Hi, >>=20 >> Several comments on data channel related drafts. >>=20 >> 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. >>=20 >> 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) >>=20 >> WebRTC W3C API has one protocol concept, 3. Protocol defined as=20 >> "Subprotocol name used for this channel" >>=20 >> 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. >>=20 >>=20 >> 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. >>=20 >> 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. >>=20 >> 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.=20 >> example: a=3Ddcmap:5000 stream=3D2;label=3D"channel 2";=20 >> subprotocol=3D"BFCP";max_retr=3D3 >>=20 >> 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... >>=20 >> = =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 >>=20 >> 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] | >> +------------------------------------+-----------+-----------+ >>=20 >> 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: >=20 > 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> = =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 >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >=20 > Best regards > Michael >>=20 >> Best Regards, >>=20 >> Jessie >>=20 >> _______________________________________________ >> rtcweb mailing list >> rtcweb@ietf.org >> https://www.ietf.org/mailman/listinfo/rtcweb >=20 >=20