Re: [rtcweb] Data Channels Proposal: Now in Internet Draft Form

"MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com> Mon, 04 March 2013 16:28 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 E181421F8935 for <rtcweb@ietfa.amsl.com>; Mon, 4 Mar 2013 08:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.949
X-Spam-Level:
X-Spam-Status: No, score=-7.949 tagged_above=-999 required=5 tests=[AWL=-2.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4]
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 yYa9nSe5XLag for <rtcweb@ietfa.amsl.com>; Mon, 4 Mar 2013 08:28:19 -0800 (PST)
Received: from smail5.alcatel.fr (smail5.alcatel.fr [62.23.212.27]) by ietfa.amsl.com (Postfix) with ESMTP id 6764621F8C2B for <rtcweb@ietf.org>; Mon, 4 Mar 2013 08:28:18 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r24GRxYr019562 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 4 Mar 2013 17:28:15 +0100
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 4 Mar 2013 17:28:12 +0100
Received: from FR711WXCHMBA03.zeu.alcatel-lucent.com ([169.254.3.55]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 4 Mar 2013 17:28:12 +0100
From: "MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com>
To: Martin Thomson <martin.thomson@gmail.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: [rtcweb] Data Channels Proposal: Now in Internet Draft Form
Thread-Index: AQHODgC+U0LQIV4uXUqD2rdW2590g5iVtT3w
Date: Mon, 4 Mar 2013 16:28:12 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A019231@FR711WXCHMBA03.zeu.alcatel-lucent.com>
References: <CABkgnnXR5Gp-C8G6AyHDMKKqE=xohkN-GKYV-=B1BhqHkxdHDw@mail.gmail.com>
In-Reply-To: <CABkgnnXR5Gp-C8G6AyHDMKKqE=xohkN-GKYV-=B1BhqHkxdHDw@mail.gmail.com>
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.13
Subject: Re: [rtcweb] Data Channels Proposal: Now in Internet Draft Form
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 16:28:23 -0000

Hi Martin, thanks for your proposal. I have some comments/questions:

1. So the label locally assigned to a data channel created in-band is not transmitted to the peer ? (note that I am fine with this)

2. Whereas defaulting properties like order or reliability is more or less OK, it seems more critical to default the subprotocol property. The app would have to parse the incoming user message to guess if this message is about 'chat' or 'file transfer'

3. Why does StreamID need to be exposed to the app ? I first thought it was to allow in-band data channel creation by a simple message sending. But then:
- either the StreamID is a parameter of send(streamID, data) - and this breaks the alignment with WebSocket API and also the app has no handle on this data channel 
- or streamID is a parameter of createDataChannel and this seems useless as the browser is able to select a new stream number internally

4.  Why does binaryPPID need to be exposed to the app ? The browser is expected to infer the message type from the data passed to send().

5. Finally to decrease the number of mismatching properties situations, you could simply assign a "Default=strict|loose" property to one of the data channels in the SDP.
If set to "strict", endpoints could only create in-band data channels for which the default set of properties applies. To create other types of data channels in-band, renegotiation is required
If set to "loose'", an endpoint receiving a user message on an closed data channel would open the data channel using these default properties. But with the risk of mismatch on subprotocol...
This would make scalable setup scenarios like:
- the SDP offer/answer exchange negotiates one 'chat' data channel, and one 'file transfer' Default data channel
- later on, either endpoint creates in-band 100 data channels for file transfer -> no renegotiation needed, no property mismatch.

This reduces the mismatching situations, in the case where one single set of properties is mostly used at a given time in the session. But the browser (or the app) has to guess at the time of SDP negotiation which set of properties should be the default, i.e. will be used more frequently than the others later on in the session. 

An extended (and deterministic) approach is to restrict the role of SDP offer/answer to the negotiation of some identified set of properties (not data channels). Then data channels are created in-band by the sending of user messages on closed streams, where each user message includes a "set of properties" identifier. You may have a look at the draft I have submitted.

Jerome


> -----Message d'origine-----
> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] 
> De la part de Martin Thomson
> Envoyé : lundi 18 février 2013 18:52
> À : rtcweb@ietf.org
> Objet : [rtcweb] Data Channels Proposal: Now in Internet Draft Form
> 
> I think that we're actually at the point where the involved 
> parties each understand each other's positions.  Now comes 
> the time to provide everyone else with a coherent proposal 
> that they can evaluate.
> 
> http://tools.ietf.org/html/draft-thomson-rtcweb-data-00
> 
> This is intended as an alternative to the mechanisms in 
> draft-ietf-rtcweb-data-channel.  It is also intended to 
> render draft-jesup-rtcweb-data-protocol unnecessary.  That 
> is, of course, as long as it meets with the approval of the 
> working group.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>