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

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Mon, 4 Mar 2013 14:36:38 +0000

Randell,

Thanks for this update. There are some points not (yet) explained in the text:

1. Following the SDP opening handshake, are the data channels implicitly opened, or does the offerer send one DATA_CHANNEL_OPEN message per new data channel ?

2. "channel is available to send as soon as the DATA_CHANNEL_OPEN has been sent". And the SACK received I guess ?

3. Assuming an endpoint creating a new offer (e.g. to reflect a change in media streams) while an SCTP association is already established. In this case, what does the SCTP association m-line contain: the unchanged list of data channels contained in the initial offer (which created the SCTP association), or the list of data channels currently opened, or .. ?
 
4. What happens if the SDP Opening Handshake agreed on some data channels using the 'chat' subprotocol, and later on an endpoint creates in-band a new channel with 'file transfer' subprotocol ?

Jerome

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> De la part de [email-masked]
> Envoyé : lundi 25 février 2013 23:40
> À : [email-masked]
> Cc : [email-masked]
> Objet : [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
>  This draft is a work item of the Real-Time Communication in 
> WEB-browsers Working Group of the IETF.
> 
> 	Title           : RTCWeb Data Channels
> 	Author(s)       : Randell Jesup
>                           Salvatore Loreto
>                           Michael Tuexen
> 	Filename        : draft-ietf-rtcweb-data-channel-04.txt
> 	Pages           : 13
> 	Date            : 2013-02-25
> 
> Abstract:
>    The Web Real-Time Communication (WebRTC) working group is 
> charged to
>    provide protocol support for direct interactive rich communication
>    using audio, video, and data between two peers' web-browsers.  This
>    document specifies the non-media data transport aspects of 
> the WebRTC
>    framework.  It provides an architectural overview of how the Stream
>    Control Transmission Protocol (SCTP) is used in the WebRTC 
> context as
>    a generic transport service allowing Web Browser to 
> exchange generic
>    data from peer to peer.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-rtcweb-data-channel
> 
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-rtcweb-data-channel-04
> 
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-data-channel-04
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 4 Mar 2013 19:46:37 +0100

> 2. "channel is available to send as soon as the DATA_CHANNEL_OPEN has been sent". And the SACK received I guess ?
The SACK is an SCTP level ack. So you only know that the SCTP stack of the peer has received it,
so you don't know if the application has received it or even processed it. So if you want some
sort of ack, you need an application level ack. This was done in the 3 way handshake stuff which
was in the older version.

In this version, the sender sends an DATA_CHANNEL_OPEN as the first message and the receiver has
to buffer user messages until the DATA_CHANNEL_OPEN message has been received in case of reordering
in the network and using unordered delivery for user messages.

Best regards
Michael

---

From: Randell Jesup <[email-masked]>
Date: Tue, 05 Mar 2013 05:17:46 -0500

> 1. Following the SDP opening handshake, are the data channels implicitly opened, or does the offerer send one DATA_CHANNEL_OPEN message per new data channel ?

One Open per new channel which can be followed immediately with data.  
If the application has some out-of-band way to know about the channels 
expected (see the text), it could indicate so (effectively allowing 
application-mediated negotiation with no Open messages in-band - not 
that I generally would suggest this for normal uses).

> 2. "channel is available to send as soon as the DATA_CHANNEL_OPEN has been sent". And the SACK received I guess ?

No SACK required I believe.  As far as SCTP is concerned, Open messages 
are just data on the stream.

> 3. Assuming an endpoint creating a new offer (e.g. to reflect a change in media streams) while an SCTP association is already established. In this case, what does the SCTP association m-line contai…

Just the listing for the association that was in the original offer 
(though this would be the SCTP SDP MMUSIC draft's issue).

> 4. What happens if the SDP Opening Handshake agreed on some data channels using the 'chat' subprotocol, and later on an endpoint creates in-band a new channel with 'file transfer' subprotocol ?

When you create a channel, it sends Open on an unused Stream.

-- 
Randell Jesup
[email-masked]

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 5 Mar 2013 09:13:35 -0800

Randell, Thanks for these changes.  I think it looks really good, and
generally meets everything I've been looking for.

On Mon, Feb 25, 2013 at 2:40 PM,  <[email-masked]> wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.
>
>    The Web Real-Time Communication (WebRTC) working group is charged to
>    document specifies the non-media data transport aspects of the WebRTC
>    Control Transmission Protocol (SCTP) is used in the WebRTC context as
>    a generic transport service allowing Web Browser to exchange generic
>    data from peer to peer.
>
>

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 6 Mar 2013 10:24:30 +0100

On 3/5/13 11:17 AM, Randell Jesup wrote:
>
>> 3. Assuming an endpoint creating a new offer (e.g. to reflect a 
>> change in media streams) while an SCTP association is already 
>> established. In this case, what does the SCTP association m-line 
>> contain: the unchanged list of data channels contained in the initial 
>> offer (which created the SCTP association), or the list of data 
>> channels currently opened, or .. ?
>
I agree this is a SCTP SDP MMUSIC draft's issue
and is something we have to agree on

---

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Wed, 6 Mar 2013 10:05:31 +0000

Thanks Michael, I still have a question/comment inline.

> De : Michael Tuexen [mailto:[email-masked]] 
> Envoyé : lundi 4 mars 2013 19:47
> À : MARCON, JEROME (JEROME)
> Cc : [email-masked]; Randell Jesup
> Objet : Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-channel-04.txt
> 
> > 1. Following the SDP opening handshake, are the data 
> channels implicitly opened, or does the offerer send one 
> DATA_CHANNEL_OPEN message per new data channel ?
> > 
> > 2. "channel is available to send as soon as the 
> DATA_CHANNEL_OPEN has been sent". And the SACK received I guess ?
> The SACK is an SCTP level ack. So you only know that the SCTP 
> stack of the peer has received it, so you don't know if the 
> application has received it or even processed it. So if you 
> want some sort of ack, you need an application level ack. 
> This was done in the 3 way handshake stuff which was in the 
> older version.
> 
> In this version, the sender sends an DATA_CHANNEL_OPEN as the 
> first message and the receiver has to buffer user messages 
> until the DATA_CHANNEL_OPEN message has been received in case 
> of reordering in the network and using unordered delivery for 
> user messages.
> 
> Best regards
> Michael

OK thanks. I am not sure to get your last point about order of delivery. You seem to refer to the SCTP endpoint behaviors (section 6.6) that unordered messages a) could bypass the in-order messages in the outbound transmission queue and b) must be delivered before in-order messages on the receiver side.

But then the DATA_CHANNEL_OPEN message should be sent 'unordered'. Otherwise this situation could occur: the sender app sends DATA_CHANNEL_OPEN 'in-order' and then immediately many 'unordered' messages. Those messages would all bypass the transmission of the DATA_CHANNEL_OPEN message.

> > 
> > 3. Assuming an endpoint creating a new offer (e.g. to 
> reflect a change in media streams) while an SCTP association 
> is already established. In this case, what does the SCTP 
> association m-line contain: the unchanged list of data 
> channels contained in the initial offer (which created the 
> SCTP association), or the list of data channels currently 
> opened, or .. ?
> > 
> > 4. What happens if the SDP Opening Handshake agreed on some 
> data channels using the 'chat' subprotocol, and later on an 
> endpoint creates in-band a new channel with 'file transfer' 
> subprotocol ?
> > 
> > Jerome
> > 
> >> De : [email-masked] 
> [mailto:[email-masked]] De la 
> >> part de [email-masked] Envoyé : lundi 25 février 
> 2013 23:40 
> >> À : [email-masked] Cc : [email-masked] Objet : 
> [rtcweb] I-D 
> >> Action: draft-ietf-rtcweb-data-channel-04.txt
> >> 
> >>

---

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Wed, 6 Mar 2013 10:40:08 +0000

Randell,

Thanks, some other comments inline. Please answer (again) to question 4, I have other pending questions related to this matter.

Jerome

> De la part de Randell Jesup
> Envoyé : mardi 5 mars 2013 11:18
> À : [email-masked]
> If the application has some out-of-band way to know about the 
> channels expected (see the text), it could indicate so 
> (effectively allowing application-mediated negotiation with 
> no Open messages in-band - not that I generally would suggest 
> this for normal uses).
> 
OK, that should be in the text.

> No SACK required I believe.  As far as SCTP is concerned, 
> Open messages are just data on the stream.
> 
I am following Michael's clarifications on this.

> Just the listing for the association that was in the original 
> offer (though this would be the SCTP SDP MMUSIC draft's issue).
> 
OK, so you said In Boston. At least the text should say when the offer should signal (or the answerer should interpret) that the list of data channels is no longer valid. How to signal this is I understand in the scope of MMUSIC which hopefully will find a cleaner way that just repeating some now invalid information. 

> When you create a channel, it sends Open on an unused Stream.

That does not answer to my question, so I reformulate: some time after the initial SDP Opening Handshake, can the DATA_CHANNEL_OPEN message create in-band a data channel with a 'subprotocol' not negotiated by the initial SDP Opening Handshake ?

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 6 Mar 2013 11:45:30 +0100

> That does not answer to my question, so I reformulate: some time after the initial SDP Opening Handshake, can the DATA_CHANNEL_OPEN message create in-band a data channel with a 'subprotocol' not ne…
I do think it should be possible to do it in-band

However I agree with you that an important side question is if/when that 
will be also signaled via SDP

/Salvatore

---

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Wed, 6 Mar 2013 12:08:54 +0000

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.

> De la part de Salvatore Loreto
> Envoyé : mercredi 6 mars 2013 11:46
> À : [email-masked]
> >> >data channels using the 'chat' subprotocol, and later on 
> an endpoint 
> >> >creates in-band a new channel with 'file transfer'
> >> >subprotocol ?
> >> >
> > That does not answer to my question, so I reformulate: some 
> time after the initial SDP Opening Handshake, can the 
> DATA_CHANNEL_OPEN message create in-band a data channel with 
> a 'subprotocol' not negotiated by the initial SDP Opening Handshake ?
> >
> However I agree with you that an important side question is 
> if/when that will be also signaled via SDP
> 
> /Salvatore

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 6 Mar 2013 13:26:48 +0100

> 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…
well, it can simply and immediately close (i.e. resetting) the outgoing 
"peer" stream

/Salvatore

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 6 Mar 2013 13:36:07 +0100

> But then the DATA_CHANNEL_OPEN message should be sent 'unordered'. Otherwise this situation could occur: the sender app sends DATA_CHANNEL_OPEN 'in-order' and then immediately many 'unordered' mess…
That is why the receiver (the JS layer) has to buffer user messages if the DATA_CHANNEL_OPEN.
You have no way to make sure the the DATA_CHANNEL_OPEN is the first one delivered on the
receiver side, if the cannel provides unordered service. If the channel provides ordered
delivery, sending the DATA_CHANNEL_OPEN ordered, ensures that the JS layer gets them in the
correct order. So one can send the DATA_CHANNEL_OPEN always ordered, but the receiving JS
layer must be prepared to receive user message before it.
It you want to avoid this, you need the solution in the older version of the ID, where
you also send user messages ordered (even on an unordered channel) until you got a
DATA_CHANNEL_RESPONSE.

Best regards
Michael

---

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Wed, 6 Mar 2013 15:03:36 +0000

> Envoyé : mercredi 6 mars 2013 13:36
> >> The SACK is an SCTP level ack. So you only know that the 
> SCTP stack 
> >> of the peer has received it, so you don't know if the 
> application has 
> >> received it or even processed it. So if you want some sort of ack, 
> >> you need an application level ack.
> >> This was done in the 3 way handshake stuff which was in the older 
> >> version.
> >> 
> >> In this version, the sender sends an DATA_CHANNEL_OPEN as 
> the first 
> >> message and the receiver has to buffer user messages until the 
> >> DATA_CHANNEL_OPEN message has been received in case of 
> reordering in 
> >> the network and using unordered delivery for user messages.
> >> 
> >> Best regards
> >> Michael
> > 
> > OK thanks. I am not sure to get your last point about order 
> of delivery. You seem to refer to the SCTP endpoint behaviors 
> (section 6.6) that unordered messages a) could bypass the 
> in-order messages in the outbound transmission queue and b) 
> must be delivered before in-order messages on the receiver side.
> > 
> > But then the DATA_CHANNEL_OPEN message should be sent 
> 'unordered'. Otherwise this situation could occur: the sender 
> app sends DATA_CHANNEL_OPEN 'in-order' and then immediately 
> many 'unordered' messages. Those messages would all bypass 
> the transmission of the DATA_CHANNEL_OPEN message.
> You have no way to make sure the the DATA_CHANNEL_OPEN is the 
> first one delivered on the receiver side, if the cannel 
> provides unordered service. If the channel provides ordered 
> delivery, sending the DATA_CHANNEL_OPEN ordered, ensures that 
> the JS layer gets them in the correct order. So one can send 
> the DATA_CHANNEL_OPEN always ordered, but the receiving JS 
> It you want to avoid this, you need the solution in the older 
> version of the ID, where you also send user messages ordered 
> (even on an unordered channel) until you got a DATA_CHANNEL_RESPONSE.
> 
> Best regards
> Michael

I agree (in the context of your proposal) on the need for buffering user messages received on a closed channel. But still not sure about sending DATA_CHANNEL_OPEN 'in-order' always. Compare the results of setting or unsetting the Unordered bit:

1a. 'in-order' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: DATA_CHANNEL_OPEN would be delivered last
1b. 'in-order' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: DATA_CHANNEL_OPEN would be delivered first

2a. 'unordered' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: DATA_CHANNEL_OPEN would be delivered first or in-between or last
2b. 'unordered' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: DATA_CHANNEL_OPEN would be delivered first

So to me sending DATA_CHANNEL_OPEN 'unordered' is faster than - or as fast as - sending it 'in-order' (i.e 2a >= 1a). Sorry if I have missed something.

Observation: it seems suspicious in any case to receive an 'in-order' user message on a closed channel.

> >> reflect a change in media streams) while an SCTP association is 
> >> already established. In this case, what does the SCTP association 
> >> m-line contain: the unchanged list of data channels 
> contained in the 
> >> initial offer (which created the SCTP association), or the list of 
> >> data channels currently opened, or .. ?
> >>> 
> >>>>  The Web Real-Time Communication (WebRTC) working group 
> is charged 
> >>>> to  provide protocol support for direct interactive rich
> >> communication
> >>>>  document specifies the non-media data transport aspects of the 
> >>>> WebRTC  framework.  It provides an architectural overview of how
> >> the Stream
> >>>>  Control Transmission Protocol (SCTP) is used in the 
> WebRTC context 
> >>>> as  a generic transport service allowing Web Browser to exchange 
> >>>> generic  data from peer to peer.
> >>>> 
> >>>>

---

From: Randell Jesup <[email-masked]>
Date: Wed, 06 Mar 2013 10:52:35 -0500

> 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…

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
[email-masked]

---

From: Randell Jesup <[email-masked]>
Date: Wed, 06 Mar 2013 11:04:28 -0500

On 3/6/2013 10:03 AM, MARCON, JEROME (JEROME) wrote:
>
>>
>> In this version, the sender sends an DATA_CHANNEL_OPEN as the first

> 1a. 'in-order' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: DATA_CHANNEL_OPEN would be delivered last

I think you may be mis-reading RFC 2960 #6.6... I think in almost all 
cases, the OPEN would be received before the unordered data.  I think 
6.6 means that unordered data following it *can* jump ahead of it in the 
reception buffer, though in practice I think that would only happen if 
the OPEN were blocked from being delivered by a missing ordered packet 
preceding it - which wouldn't exist in this protocol.

However, if this is incorrect, nothing would be harmed by sending OPENs 
for unordered channels in an unordered fashion, so long as they're reliable.

-- 
Randell Jesup
[email-masked]

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 6 Mar 2013 17:26:07 +0100

> 1a. 'in-order' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: DATA_CHANNEL_OPEN would be delivered last
No. If the DATA_CHANNEL_OPEN is received first by SCTP, it will be received first by the App.
> 1b. 'in-order' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: DATA_CHANNEL_OPEN would be delivered first
Correct.
> 2a. 'unordered' DATA_CHANNEL_OPEN sent, then 'unordered' messages sent: DATA_CHANNEL_OPEN would be delivered first or in-between or last
Correct.
> 2b. 'unordered' DATA_CHANNEL_OPEN sent, then 'ordered' messages sent: DATA_CHANNEL_OPEN would be delivered first
No. If the ordered message is received first, it gets delivered first.

Please note that the network layer might reorder packets or packets get lost and needs to be retransmitted.

Best regards
Michael

---

From: Michael Tuexen <[email-masked]>
Date: Wed, 6 Mar 2013 17:29:49 +0100

On Mar 6, 2013, at 5:04 PM, Randell Jesup wrote:

> I think you may be mis-reading RFC 2960 #6.6... I think in almost all cases, the OPEN would be received before the unordered data.  I think 6.6 means that unordered data following it *can* jump ahead of it in the reception buffer, though in practice I think that would only happen if the OPEN were blocked from being delivered by a missing ordered packet preceding it - which wouldn't exist in this protocol.
6.6. has no mandatory text on this... We push messages in the socket buffer as soon as we can. When they
are read by the application is up to the application.

The text allows you to bypass the ordering queue with an emphasis on preference to unordered messages.
But implementation details might come into the game.

Using a callback API allows to deliver as soon as possible, but if there is a socket buffer in the
game things might happen there...

Best regards
Michael
> 
> However, if this is incorrect, nothing would be harmed by sending OPENs for unordered channels in an unordered fashion, so long as they're reliable.
>

---

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Mon, 11 Mar 2013 18:51:45 +0000

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

* 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 ?

Jerome

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

channel.close();

--
Randell Jesup
[email-masked]

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 11 Mar 2013 20:22:22 +0100

>   messages as there are combinations of {subprotocol, property variants}

Is there any reason why the app that desires to use such a protocol over 
a data channel shouldn't send a new message (defined in the protocol) 
after the DATA_CHANNEL_OPEN saying what the desired properties are, and 
with an accept/reject message on the return channel?

One of the desirable properties of DATA_CHANNEL_OPEN is that it's 
simple. I'd like to keep it that way.

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 11 Mar 2013 15:23:50 -0400

> - 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...
> 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 CH…
I don't think it makes sense to extend SCTP instead of doing this on top of SCTP, if you need.

Best regards
Michael

---

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Mon, 11 Mar 2013 21:20:53 +0000

Thanks again Michael. Inline my [JM1] comments.

________________________________________
De : Michael Tuexen [[email-masked]]
Date d'envoi : lundi 11 mars 2013 20:23
À : MARCON, JEROME (JEROME)
Cc: Randell Jesup; [email-masked]
Objet : Re: [rtcweb]  I-D Action: draft-ietf-rtcweb-data-channel-04.txt

[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

[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

---

From: "MARCON, JEROME (JEROME)" <[email-masked]>
Date: Mon, 11 Mar 2013 22:08:53 +0000

[JM1]
________________________________________
De : [email-masked] [[email-masked]] de la part de Harald Alvestrand [[email-masked]]
Date d'envoi : lundi 11 mars 2013 20:22
À : [email-masked]
Objet : Re: [rtcweb] RE : I-D Action: draft-ietf-rtcweb-data-channel-04.txt

[JM1] All right, this would work in many cases (brand-new protocols, and protocols "adapted" over RTCWeb data channels, which have or can easily integrate capabilities negotiation). In some cases though, that would be challenging: e.g. the character-oriented T.140 protocol.

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 11 Mar 2013 19:15:08 -0400

> Thanks again Michael. Inline my [JM1] comments.
I agree, having an error message and defining what error is sent back if an unknown message
is received does make sense.
> [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.
That is the drawback...
> Also a true protocol on top of SCTP would define a DATA_CHANNEL_CLOSE user message.
But it wouldn't really help, since you can't make sure that the message is received as
the last message. So using an SCTP mechanism for resetting streams makes sense...

Best regards
Michael

---

From: Randell Jesup <[email-masked]>
Date: Tue, 12 Mar 2013 04:00:24 -0400

On 3/11/2013 5:20 PM, MARCON, JEROME (JEROME) wrote:
>
> > Assuming that some day a spec defines the transport of T.140 (or 
> whatever similar protocol) over RTCWeb data channels
> > - of which some are assymetric between the endpoints (like the 
> "characters per second" defined in [RFC4103].
> >
> [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.

It you need to do a more complex negotiation, you have several choices.  
One would be:

Open a reliable data channel for negotiation (0 RTT) (flagged by label & 
protocol).  Over that channel, immediately send a message that sets up 
an offer for T.140 (take your pick on format. A JS app would likely use 
JSON), with a channel which was preset with the appropriate options ("I 
expect to receive data on this channel with these options").  The 
answerer can send back the response (on the negotiation channel), and 
also say "I expect data on this channel with these options").  At this 
point, the T.140 channel is open, and as soon as the response is 
received by the offerer, both sides know it.

If this sounds very much like "fast-path re-negotiation" for JSEP, it 
is.  Once you have DataChannels, you can leverage them to do a lot of 
things.  This sort of sequence is enabled by the ability added to allow 
external negotiation.  This is as fast as any other mechanism (and 
faster than any that goes via a signaling server) - 3 messages, 1 RTT 
total.  (Open, Offer -> Answer)

You can do this in SDP if you wish (and are willing to parse SDP, or 
whatever limited SDP  you need).  As mentioned, I normally would suggest 
JSON or something like that for JS Apps.)

You can also do external negotiation over whatever channel and method 
you like.

-- 
Randell Jesup
[email-masked]