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

"MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com> Wed, 06 March 2013 01:20 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 36F0121F859C for <rtcweb@ietfa.amsl.com>; Tue, 5 Mar 2013 17:20:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.374
X-Spam-Level:
X-Spam-Status: No, score=-9.374 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_48=0.6, 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 W0gtUuYhmPlR for <rtcweb@ietfa.amsl.com>; Tue, 5 Mar 2013 17:20:22 -0800 (PST)
Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by ietfa.amsl.com (Postfix) with ESMTP id 94DC421F858C for <rtcweb@ietf.org>; Tue, 5 Mar 2013 17:20:22 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r261KKgV019111 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 6 Mar 2013 02:20:20 +0100
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 6 Mar 2013 02:20:20 +0100
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.26]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Wed, 6 Mar 2013 02:20:20 +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+U0LQIV4uXUqD2rdW2590g5iVtT3wgAARooCAAgaxUA==
Date: Wed, 6 Mar 2013 01:20:19 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A02039F@FR711WXCHMBA02.zeu.alcatel-lucent.com>
References: <CABkgnnXR5Gp-C8G6AyHDMKKqE=xohkN-GKYV-=B1BhqHkxdHDw@mail.gmail.com> <39821B4C400EC14DAD4DB25330A9271A019231@FR711WXCHMBA03.zeu.alcatel-lucent.com> <CABkgnnU1JRZb9QUiu1Z1v6Fa0=bX4UbA4aKhF21FP8KH-V7g7A@mail.gmail.com>
In-Reply-To: <CABkgnnU1JRZb9QUiu1Z1v6Fa0=bX4UbA4aKhF21FP8KH-V7g7A@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.84
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: Wed, 06 Mar 2013 01:20:24 -0000

Thanks. Two new comments inline.
 
Also, if you could outline the Data Channel API needed to support your proposal, that would help the understanding.

> -----Message d'origine-----
> De : Martin Thomson [mailto:martin.thomson@gmail.com] 
> Envoyé : lundi 4 mars 2013 18:01
> À : MARCON, JEROME (JEROME)
> Cc : rtcweb@ietf.org
> Objet : Re: [rtcweb] Data Channels Proposal: Now in Internet 
> Draft Form
> 
> Brief answers inline.
> 
> On 4 March 2013 08:28, MARCON, JEROME (JEROME) 
> <jerome.marcon@alcatel-lucent.com> wrote:
> >
> > 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)
> 
> The label is a handle that is provided to the application as 
> a convenience.  The label is a new invention, which I'm not 
> certain we entirely need.  It might provide some use, but 
> it's unclear how it adds value over the subprotocol label.
> 
> > 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'
> 
> Actually, in most cases, an application will only ever 
> receive packets that they know about beforehand.  If they 
> need to distinguish between chat and file transfer, they will 
> have established conventions for identifying those packets.  
> PPID is one possible convention, though I note that most uses 
> of SCTP I've seen don't use more than one value, so most code 
> ends up ignoring the PPID.
> 
> I share the same leeriness about the "protocol" label used in 
> thewebsocketprotocol.

Before the 'subprotocol' concept was ever discussed, I thought the SDP O/A should allow to negotiate the PPID to use for each channel (applied to all messages of this channel) where the PPID would be a true IANA-registered protocol defined over SCTP. Now I am fine with the negotiation of 'subprotocol' value.

Randell's proposal is reserving the PPID for the per-message text/binary/control signaling, so 'subprotocol' and PPID are orthogonal. But your proposal is exposing the per-message PPID to the app (regardless of the negotiated subprotocol). So the roles of 'subprotocol' and PPID seem to potentially overlap (although semantically the PPID signals some protocol over a unidirectional SCTP stream, whereas 'subprotocol' rather signals some protocol over a bi-directional RTCWeb data channel). Maybe you have some thoughts on the potential relationships between a registered PPID and a registered subprotocol (1-1, 1-N, N-1, etc.). Example: if I write an RFC porting a file transfer protocol over RTCWeb data channel, would the RFC reserve exclusively one PPID XXX and one 'file transfer XXX' subprotocol value ? 

What bothers me so far in your proposal is the 'try and guess' property selection process left to the app when a message is received on a closed channel, for the 'subprotocol' property in particular. But if the subprotocol can be deterministically inferred from the incoming user message PPID, then that's a lot better.  
> 
> > 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
> 
> Stream ID is exposed to the app because it allows the app to 
> create their own usage pattern.  It can create the streams it 
> wants and attach meaning to those numbers.  That said, stream 
> IDs are allocated automatically by the browser for most uses. 
>  I'd expect that streamId would be an optional constraint 
> (i.e., optional in usage) on channel creation.
> 
> There is no in-band protocol, except for the one that the 
> application uses.  That's important.
> 

> > 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().
> 
> binaryPPID allows the application to generate (though not 
> consume, except in constrained cases) SCTP that can be 
> consumed by any application.  The browser doesn't "infer" 
> anything about message types, other than when messages use 
> the textual PPID, in which case they are surfaced as strings 
> rather than the specified binary type (a Blob or ArrayBuffer).
> 

> > 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.
> 
> That's unnecessary.  If I want an application that has one "special"
> channel and an arbitrary number of "normal" channels, I can 
> do exactly as you say and then set the properties of those 
> spontaneously created channels as they appear.  It doesn't 
> require any more standardization or browser machinery:
> 
> pc.addEventListener('datachannel', function(e) {
>   var fileTransferChannel = e.channel;
>   fileTransferChannel.ordered = true;
>   fileTransferChannel.subprotocol = 'filetransfer'; });
> 
> > 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.
> 
> I didn't see a specific need for negotiating properties in 
> such a generic fashion.  Ultimately, each property needs some 
> semantics when you use it, so it seemed excessive.  In SDP at 
> least, the extension mechanism is well enough understood to 
> be able to support extension enough to allow for new 
> properties to be defined (like ordering, which I omitted from 
> my draft by mistake).
> 
> That said, if you are defining an in-band protocol (a bad 
> idea in my opinion), the idea that properties are generic 
> makes a great deal of sense.  That allows applications to 
> define what they need and allows them to avoid unnecessary noise.

Like you advise, I also propose is an out-of-band SDP negotiation of sets of generic properties, with no properties carried in-band. Where I differ is that the selection of some properties (e.g. subprotocol) to apply to a channel created from an incoming message must be always (not just sometimes) deterministic. 
 
> 
> --Martin
>