Re: [rtcweb] TR : New Version Notification for draft-marcon-rtcweb-data-channel-management-00.txt

"MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com> Mon, 04 March 2013 13:27 UTC

Return-Path: <jerome.marcon@alcatel-lucent.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 643C521F8A7B for <rtcweb@ietfa.amsl.com>; Mon, 4 Mar 2013 05:27:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.249
X-Spam-Level:
X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPcUWaL0fNrM for <rtcweb@ietfa.amsl.com>; Mon, 4 Mar 2013 05:27:40 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 732AF21F8A6E for <rtcweb@ietf.org>; Mon, 4 Mar 2013 05:27:40 -0800 (PST)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r24DR7HQ000549 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Mar 2013 14:27:37 +0100
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Mar 2013 14:27:01 +0100
Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.55]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Mon, 4 Mar 2013 14:27:02 +0100
From: "MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com>
To: Randell Jesup <randell-ietf@jesup.org>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] TR : New Version Notification for draft-marcon-rtcweb-data-channel-management-00.txt
Thread-Index: AQHODm2XDcYJNXiiNUSgiH+65Ett8JiVc4VA
Date: Mon, 4 Mar 2013 13:27:01 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A01918D@FR711WXCHMBA03.zeu.alcatel-lucent.com>
References: <20130218233047.19414.47123.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A012598@FR711WXCHMBA03.zeu.alcatel-lucent.com> <51232071.3070207@jesup.org>
In-Reply-To: <51232071.3070207@jesup.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80
Subject: Re: [rtcweb] TR : New Version Notification for draft-marcon-rtcweb-data-channel-management-00.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Mar 2013 13:27:41 -0000

Thanks Randell for you review. My replies inline. 

> -----Message d'origine-----
> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] 
> De la part de Randell Jesup
> Envoyé : mardi 19 février 2013 07:49
> À : rtcweb@ietf.org
> Objet : Re: [rtcweb] TR : New Version Notification for 
> draft-marcon-rtcweb-data-channel-management-00.txt
> 
> On 2/18/2013 7:07 PM, MARCON, JEROME (JEROME) wrote:
> > Hi,
> >
> > I have submitted a draft proposing a new way of setting up 
> data channels, based on the concept of data channel 
> configurations. It uses a lightweight SDP signaling coupled 
> with a lightweight in-band signaling (not an in-band 
> protocol). I think it can handle efficiently the most 
> demanding setup scenarios. The proposal is besides designed 
> with the intent to not impact on current browser API.
> 
> Thanks.  Still reading, but an initial comment:
> 
> "Whenever the application creates a new data channel, the 
> browser internally checks if the passed set of parameters 
> strictly matches an existing configuration, and if not 
> generates a new configuration identifier for this set. In the 
> latter case only does the browser trigger the application for 
> an SDP renegotiation."
> 
> Wouldn't this occur on almost every channel because of label 
> values?  Or are you assuming applications won't actually use labels?

In this first version of the proposal, the use of labels is still undefined, but (for the sale of scalability) it would for now remain a local data channel property not transmitted to the peer (should this local property be useful to something).

I would appreciate some clarifications on the usefulness of labels in the context of data channels. W3C says nothing about it. Probably - if transmitted to the peer - it can assist the user consent decision. But then assuming the offer is for opening 100 data channels for file transfer (each channel with a distinct label), would the answerer's consent be asked 100 times (once per distinct label) ? Probably asking once "do you agree on some file transfers" is enough (and better). And the 'file transfer' information is carried by the subprotocol property, not the label.     

> 
> "For each data channel configuration in the offer that is 
> accepted by the answerer, the answerer echoes in the answer 
> the configurations supported and accepted. Once the offerer 
> receives the answer and (in case of an initial offer) the 
> SCTP initialization is complete, each data channel locally 
> created using one of the accepted configurations is signaled 
> to the application as open for transmission."
> 
> There's a bunch of API to surface here in order to support 
> O/A ("for each ... that is accepted by the answerer...").
> 
> "By convention, the inbound and outbound streams of a data 
> channel have the same SCTP stream number. This stream number 
> is selected by the first endpoint sending a user message on 
> this channel. Till this happens, an open data channel has no 
> assigned stream number."
> 
> How do you handle glare? (i.e. both sides start to send on 
> stream 5 at the same time)
> 
There are two methods proposed in section 6.5. You seem to be supportive of the 2nd method (even/odd stream number ownership convention).

> "Data channel messages are sent as SCTP user messages, 
> preceded in the DATA chunk User Data field by two bytes 
> specifying data channel configuration identifier as well as 
> the message data framing type (textual or binary)."
> 
> Aha.  So you've moved this into a true inband protocol with 
> data framing.  The current draft sends data messages with no 
> added framing required.

Please explain why data framing is an issue. WebSocket protocol does this. The proposal also only reserves a unique PPID for the entire RTCWeb data channel functionality. Personally, I find it ackward to reserve a PPID for something like "plain transmission of any binary data or UTF-8 stream". It seemed to me that each PPID today registered with IANA is identifying a true self-contained protocol. 

> 
> --
> Randell Jesup
> randell-ietf@jesup.org
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>