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

Thanks again Michael. Inline my [JM1] comments.

________________________________________
De : Michael Tuexen [Michael.Tuexen@lurchi.franken.de]
Date d'envoi : lundi 11 mars 2013 20:23
À : 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 "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
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 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 structures (as the spec says), the spec should specify how one endpoint can discover which message types the other endpoint supports. Of course the endpoint could 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 (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:
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 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
> - 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 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.
>
> 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
>