Return-Path: 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 EDA6621F8FEE for ; Mon, 11 Mar 2013 14:20:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.83 X-Spam-Level: X-Spam-Status: No, score=-9.83 tagged_above=-999 required=5 tests=[AWL=0.418, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, 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 qsZYVKGFYDBs for ; Mon, 11 Mar 2013 14:20:58 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 40FF221F8F7A for ; Mon, 11 Mar 2013 14:20:58 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r2BLKtRS006047 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 11 Mar 2013 22:20:55 +0100 Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (135.239.2.74) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (135.120.45.64) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 11 Mar 2013 22:20:54 +0100 Received: from FR711WXCHMBA02.zeu.alcatel-lucent.com ([169.254.2.26]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 11 Mar 2013 22:20:55 +0100 From: "MARCON, JEROME (JEROME)" To: Michael Tuexen , "rtcweb@ietf.org" Thread-Topic: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt Thread-Index: AQHOHo4Bj9+KsPxJJE2oLAO4Ougqn5ig+Bfx Date: Mon, 11 Mar 2013 21:20:53 +0000 Message-ID: <39821B4C400EC14DAD4DB25330A9271A024714@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> <39821B4C400EC14DAD4DB25330A9271A024649@FR711WXCHMBA02.zeu.alcatel-lucent.com>, <2024BD14-E25C-426F-B046-46D61AF7077C@lurchi.franken.de> In-Reply-To: <2024BD14-E25C-426F-B046-46D61AF7077C@lurchi.franken.de> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: multipart/alternative; boundary="_000_39821B4C400EC14DAD4DB25330A9271A024714FR711WXCHMBA02zeu_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: Randell Jesup 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2013 21:21:00 -0000 --_000_39821B4C400EC14DAD4DB25330A9271A024714FR711WXCHMBA02zeu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks again Michael. Inline my [JM1] comments. ________________________________________ De : Michael Tuexen [Michael.Tuexen@lurchi.franken.de] Date d'envoi : lundi 11 mars 2013 20:23 =C0 : MARCON, JEROME (JEROME) Cc: Randell Jesup; rtcweb@ietf.org Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt On Mar 11, 2013, at 2:51 PM, MARCON, JEROME (JEROME) wrote: > Randell, > > 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 "character= s 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 Why is it not extensible? We have a message type and you could simply define another message... [JM1]. Mmh, then the spec defining T.140 (or whatever) over data channels (= and willing to add a new property like "cps") would have to define a new me= ssage type - and more less its own DATA_CHANNEL_OPEN structure? That's a c= ostly extensibility. Also, given that different message types likely imply incompatible structur= es (as the spec says), the spec should specify how one endpoint can discove= r which message types the other endpoint supports. Of course the endpoint c= ould reject the message by a close() again. But then this close() would hav= e three hats :) - close a channel - reject some parameters of an incoming DATA_CHANNEL_OPEN - reject the format of an incoming DATA_CHANNEL_OPEN > > * Because the successful response to an open data channel request does no= t exist: > - it is not possible to agree on assymetric property values > > * Because the error response to an open data channel has no payload (erro= r): > - an endpoint cannot easily know if this subprotocol is supported or whic= h reliability properties are supported. Unless it sends as many DATA_CHANNE= L_OPEN > messages as there are combinations of {subprotocol, property variants} > > Besides, if after unsuccessful tries (DATA_CHANNEL_OPEN) and errors (clos= e() ), the endpoint decides to go for an SDP renegotiation: > - first this might be for nothing (the peer might not support anything af= ter all), > - second the design would be more complex, because for now the proposal = assumes that SDP negotiation only happens once, in the offer/answer establi= shing the SCTP association, when no data channels exist. > > This might have been discussed before, but in the eventually that an inba= nd 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 Channe= l Control CHUNK) carrying request and response parameters in a bi-direction= al way. Most SCTP extensions are defined this way, aren't they ? And with t= he additional benefits: I don't think it makes sense to extend SCTP instead of doing this on top of= SCTP, if you need. [JM1]. On top of SCTP, and to reduce the RTT, you had to drop DATA_CHANNEL_= OPEN_RESPONSE at the cost of assymetric negotiation and proper error handli= ng. Also a true protocol on top of SCTP would define a DATA_CHANNEL_CLOSE user = message. Best regards Michael > - 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 ? > > Jerome > > ________________________________________ > De : rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] de la part de Rand= ell Jesup [randell-ietf@jesup.org] > Date d'envoi : mercredi 6 mars 2013 16:52 > =C0 : 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. > > channel.close(); > > 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 > randell-ietf@jesup.org > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb > --_000_39821B4C400EC14DAD4DB25330A9271A024714FR711WXCHMBA02zeu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks again Michael. Inline my [JM1] comments.

________________________________________
De : Michael Tuexen [Michael.Tuexen@lurchi.franken.de]
Date d'envoi : lundi 11 mars 2013 20:23
=C0 : MARCON, JEROME (JEROME)
Cc: Randell Jesup; rtcweb@ietf.org
Objet : Re: [rtcweb]  I-D Action: draft-ietf-rtcweb-data-channel-04.tx= t

On Mar 11, 2013, at 2:51 PM, MARCON, JEROME (JEROME) wrote:

> Randell,
>
> Assuming that some day a spec defines the transport of T.140 (or whate= ver 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 "c= haracters 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_OPE= N
Why is it not extensible? We have a message type and you could simply
define another message...

[JM1]. Mmh, then the spec defining T.140 (or whatev= er) over data channels (and willing to add a new property like "cps&qu= ot;) would have to define a new message type  - and more less its own = DATA_CHANNEL_OPEN structure? That's a costly extensibility.

Also, given that different message types likely imply incompatible structur= es (as the spec says), the spec should specify how one endpoint can discove= r which message types the other endpoint supports. Of course the endpoint c= ould reject the message by a close() again. But then this close() would have three hats :)
- close a channel
- reject some parameters of an incoming DATA_CHANNEL_OPEN
- reject the format of an incoming 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 (e= rror):
> - an endpoint cannot easily know if this subprotocol is supported or w= hich reliability properties are supported. Unless it sends as many DATA_CHA= NNEL_OPEN
> messages as there are combinations of {subprotocol, property variants}=
>
> Besides, if after unsuccessful tries (DATA_CHANNEL_OPEN) and errors (c= lose() ), 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 p= roposal 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 i= nband protocol is really unavoidable (I still hope it is not), another opti= on would have been to base this protocol on a new CHUNK type (e.g. Data Cha= nnel 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:
I don't think it makes sense to extend SCTP instead of doing this on top of= SCTP, if you need.

[JM1]. On top of SCTP, and = to reduce the RTT, you had to drop DATA_CHANNEL_OPEN_RESPONSE at the cost o= f assymetric negotiation and proper error handling.
Also a true protocol on top of SCTP would define a DATA_CHANNEL_CLOSE user = message.

Best regards
Michael
> - 1 RTT also
> - built-in parameter extensibility
> - refined error handling, e.g. report which parameter caused an error<= br> > - control messages not mixed with application messages
> - proper data channel closing (the use of SSN reset is more like a tri= ck; also open() and close() messages to not belong to the same protocol/lay= er)
> - ability to define optimized retransmission procedures - those inheri= ted from user messages might not be the best one
> - ...
>
> I guess this has been discussed in the past ?
>
> Jerome
>
> ________________________________________
> De : rtcweb-bounces@ietf.org [rtcweb-bounces@ietf.org] de la part de R= andell Jesup [randell-ietf@jesup.org]
> Date d'envoi : mercredi 6 mars 2013 16:52
> =C0 : 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 exi= sts in this new draft version - I wonder how the peer can reject an incomin= g DATA_CHANNEL_OPEN message signaling a 'subprotocol' it does not support.<= br> >
> channel.close();
>
> I.e. there's no explicit prior-to-connect rejection, you simply state<= br> > 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 f= or this.
>
> --
> Randell Jesup
> randell-ietf@jesup.org
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>
--_000_39821B4C400EC14DAD4DB25330A9271A024714FR711WXCHMBA02zeu_--