Subject: [rtcweb] Data Channel Protocol: Data before DATA_CHANNEL_ACK

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 10:20:02 +0000

Hi,

As is defined in the data channel protocol, an entity can send data once DATA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is received.

What is the reason for allowing data to be sent before DATA_CHANNEL_ACK? The sender may not even know (depends on whatever external negotiation mechanisms are used) whether the remote peer supports the protocol to begin with.

It think it would be good to allow the remote peer to accept (DATA_CHANNEL_ACK) or reject (stream reset) the DATA_CHANNEL_OPEN before data is sent.

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 10 Feb 2014 10:20:52 -0800

If you have to wait for the ACK, it's one more RTT you have to wait before
you can send data.  We've already got many RTTs form ICE and DTLS and
what's built into SCTP.  We originally didn't have an ACK message at all,
in large part because we didn't want more RTTs.  The ACK was put in to
handle the edge case of unordered data arriving before the OPEN message.
 But we added it in a way that it doesn't add more RTTs.

On Mon, Feb 10, 2014 at 2:20 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> As is defined in the data channel protocol, an entity can send data once
> DATA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is
> received.
>
> What is the reason for allowing data to be sent before DATA_CHANNEL_ACK?
> The sender may not even know (depends on whatever external negotiation
> mechanisms are used) whether the remote peer supports the protocol to begin
> with.
>
> It think it would be good to allow the remote peer to accept
> (DATA_CHANNEL_ACK) or reject (stream reset) the DATA_CHANNEL_OPEN before
> data is sent.
>
> Regards,
>
> Christer
>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 19:55:54 +0000

Hi Peter,

> If you have to wait for the ACK, it's one more RTT you have to wait before you can send data.  We've already 
> got many RTTs form ICE and DTLS and what's built into SCTP.  We originally didn't have an ACK message at all, in 
> large part because we didn't want more RTTs.  The ACK was put in to handle the edge case of unordered data arriving 
> before the OPEN message.  But we added it in a way that it doesn't add more RTTs.

But, you may not even know whether I support the protocol you are sending. What should I do if I don't like/support what you send?

I think it would be useful to have a REJ message, so that I can explicitly tell you that I don't want what you send - rather than me reseting the stream, or me not sending an ACK and hope that you will eventually stop sending data.

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Mon, 10 Feb 2014 12:04:38 -0800

On Mon, Feb 10, 2014 at 11:55 AM, Christer Holmberg <
[email-masked]> wrote:

> > got many RTTs form ICE and DTLS and what's built into SCTP.  We
> originally didn't have an ACK message at all, in
> > large part because we didn't want more RTTs.  The ACK was put in to
> handle the edge case of unordered data arriving
> But, you may not even know whether I support the protocol you are sending.
> What should I do if I don't like/support what you send?
>
>
​The signalling is up to the application to define.  If your application
wants to send a message from the receiver to the sender saying "I support
X" or "please send me X", then by all means​ add that to your application,
and don't call channel.send() until the sender knows it should send.

> I think it would be useful to have a REJ message, so that I can explicitly
> tell you that I don't want what you send - rather than me reseting the
> stream, or me not sending an ACK and hope that you will eventually stop
> sending data.
>

​​The signalling is up to the application to define.  If your application
wants to send a message from the receiver to the sender saying "I don't
support X" or "please don't send me X", then by all means​ add that to your
application, and don't call channel.send() if the receiver says it doesn't
want the message.

I think what is already in the standard is sufficient for your use case.
 You just need to add a little application-specific signalling.  I don't
think the in-band signalling is the right place to put things like this.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 20:18:05 +0000

>I think what is already in the standard is sufficient for your use case.  You just need to add a little application-specific signalling.  I don't think the in-band signalling is the right place to put things like this.

If it is sufficient to use in-band signalling to say ”I would like to send you this data”, I think it is equally sufficient to use in-band signaling to reply “No, I don’t want that data”...

Anyway, if people don't think it's needed, then I guess one can simply reset the stream.

Regards,

Christer

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 10 Feb 2014 21:23:51 +0100

> Anyway, if people don't think it's needed, then I guess one can simply reset the stream.
Exactly. If the peer resets the stream before sending a DATA_CHANNEL_ACK, it is an error.
Section 6 of draft-ietf-rtcweb-data-protocol-02.txt contains

Therefore, receiving an SCTP stream reset request for a stream on which no DATA_CHANNEL_ACK message has been received indicates to the sender of the corresponding DATA_CHANNEL_OPEN message the failure of the data channel setup procedure.

Best regards
Michael

---

From: Randell Jesup <[email-masked]>
Date: Tue, 11 Feb 2014 16:46:51 -0800

On 2/10/2014 10:20 AM, Peter Thatcher wrote:
> If you have to wait for the ACK, it's one more RTT you have to wait 
> before you can send data.  We've already got many RTTs form ICE and 
> DTLS and what's built into SCTP.  We originally didn't have an ACK 
> message at all, in large part because we didn't want more RTTs.  The 
> ACK was put in to handle the edge case of unordered data arriving 

Exactly.   Especially at call-start.

>
>
> On Mon, Feb 10, 2014 at 2:20 AM, Christer Holmberg 
> <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi,
>
>     As is defined in the data channel protocol, an entity can send
>     data once DATA_CHANNEL_OPEN has been sent, before the associated
>     DATA_CHANNEL_ACK is received.
>
>     What is the reason for allowing data to be sent before
>     DATA_CHANNEL_ACK? The sender may not even know (depends on
>     whatever external negotiation mechanisms are used) whether the
>     remote peer supports the protocol to begin with.
>
>     (DATA_CHANNEL_ACK) or reject (stream reset) the DATA_CHANNEL_OPEN
>     before data is sent.
>

"Rejection" of a channel can be done be either ignoring it (drop the 
channel reference on the floor), or actively closing it 
(channel.close(), then drop it on the floor).  This was agreed on a long 
time ago.

-- 
Randell Jesup
[email-masked]