[rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.txt

"MARCON, JEROME (JEROME)" <jerome.marcon@alcatel-lucent.com> Mon, 11 March 2013 18:51 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 []) by ietfa.amsl.com (Postfix) with ESMTP id A8F5C21F8E32 for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 11:51:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.989
X-Spam-Status: No, score=-7.989 tagged_above=-999 required=5 tests=[AWL=-1.740, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id NZIUfRVTAT6j for <rtcweb@ietfa.amsl.com>; Mon, 11 Mar 2013 11:51:57 -0700 (PDT)
Received: from smail6.alcatel.fr (smail6.alcatel.fr []) by ietfa.amsl.com (Postfix) with ESMTP id BA08B21F8E1D for <rtcweb@ietf.org>; Mon, 11 Mar 2013 11:51:56 -0700 (PDT)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com []) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BIplUo018527 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Mar 2013 19:51:53 +0100
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com ( by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ( with Microsoft SMTP Server (TLS) id; Mon, 11 Mar 2013 19:51:46 +0100
Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([]) with mapi id 14.02.0247.003; Mon, 11 Mar 2013 19:51:46 +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] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
Thread-Index: AQHOE6kv4waTKhEPkEqZxW6NBQbqlZiVlNqAgAFIbACAAaCdEP//+XgAgAAl0CCAAC/8gIAIC3cR
Date: Mon, 11 Mar 2013 18:51:45 +0000
Message-ID: <39821B4C400EC14DAD4DB25330A9271A024649@FR711WXCHMBA02.zeu.alcatel-lucent.com>
References: <20130225224014.18570.20111.idtracker@ietfa.amsl.com> <39821B4C400EC14DAD4DB25330A9271A0191D3@FR711WXCHMBA03.zeu.alcatel-lucent.com> <5135C64A.50302@jesup.org> <39821B4C400EC14DAD4DB25330A9271A02108E@FR711WXCHMBA02.zeu.alcatel-lucent.com> <51371E4A.4040602@ericsson.com> <39821B4C400EC14DAD4DB25330A9271A0214C1@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <51376643.8090204@jesup.org>
In-Reply-To: <51376643.8090204@jesup.org>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.69 on
Subject: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.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, 11 Mar 2013 18:51:57 -0000


Assuming that some day a spec defines the transport of T.140 (or whatever similar protocol) over RTCWeb data channels
- with a registered subprotocol
- with multiple reliability options supported
- requiring some new data channel properties
- of which some are assymetric between the endpoints (like the "characters per second" defined in [RFC4103].

Then (in the current version of your proposal) it seems to me that
* Because current DATA_CHANNEL_OPEN syntax is not extensible:
- it is not possible to carry these new properties in DATA_CHANNEL_OPEN

* Because the successful response to an open data channel request does not exist:
- it is not possible to agree on assymetric property values

* Because the error response to an open data channel has no payload (error):
- an endpoint cannot easily know if this subprotocol is supported or which reliability properties are supported. Unless it sends as many DATA_CHANNEL_OPEN
 messages as there are combinations of {subprotocol, property variants}

Besides, if after unsuccessful tries (DATA_CHANNEL_OPEN) and errors (close() ), the endpoint decides to go for an SDP renegotiation:
- first this might be for nothing (the peer might not support anything after all),
- second  the design would be more complex, because for now the proposal assumes that SDP negotiation only happens once, in the offer/answer establishing the SCTP association, when no data channels exist.   
This might have been discussed before, but in the eventually that an inband protocol is really unavoidable (I still hope it is not), another option would have been to base this protocol on a new CHUNK type (e.g. Data Channel Control CHUNK) carrying request and response parameters in a bi-directional way. Most SCTP extensions are defined this way, aren't they ? And with the additional benefits:
- 1 RTT also
- built-in parameter extensibility
- refined error handling, e.g. report which parameter caused an error
- control messages not mixed with application messages
- proper data channel closing (the use of SSN reset is more like a trick; also open() and close() messages to not belong to the same protocol/layer)
- ability to define optimized retransmission procedures - those inherited from user messages might not be the best one 
- ...
I guess this has been discussed in the past ?


De : rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] de la part de Randell Jesup [randell-ietf@jesup.org]
Date d'envoi : mercredi 6 mars 2013 16:52
À : rtcweb@ietf.org
Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt

On 3/6/2013 7:08 AM, MARCON, JEROME (JEROME) wrote:
> But then - and given that DATA_CHANNEL_OPEN_RESPONSE no longer exists in this new draft version - I wonder how the peer can reject an incoming DATA_CHANNEL_OPEN message signaling a 'subprotocol' it does not support.


I.e. there's no explicit prior-to-connect rejection, you simply state
instead "I'm not interested" and close it.  This resets the streams, and
causes the other side to be notified of the close. You're correct in
that this is not distinguished from other reasons to close() it; if
those are needed you should either negotiate it out-of-band, or make a
rejection part of the protocol you run over it.  This is entirely within
the application's domain.  Most applications would have no need for this.

Randell Jesup

rtcweb mailing list