Subject: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 31 May 2018 11:24:25 -0700

One might expect that a "reliable" data channel is guaranteed to be, well,
reliable. But in current implementations, the first messages may be lost if
the application is negotiating the channels out-of-band, and creates the
receiving channel too late.

Here's a fiddle that demonstrates this (happens with Chrome and Firefox):
https://jsfiddle.net/o2m8tp20/

Normally this isn't an issue, because a typical application would create
the out-of-band negotiated channels before the first offer/answer is
complete, and thus before the SCTP association is established. Meaning that
by the time a data channel is "open", it's guaranteed that the other peer
has a corresponding channel.

But if for whatever reason, an application creates a data channel *after*
the SCTP association is established, then it will instantly be "open" as
soon as it's created. If a message is sent at this point, and it's received
by the other peer before it's created its corresponding data channel, then
the message will just be discarded.

So, how should we deal with this? Some possibilities:

   1. Say "this is expected behavior" and document it better, breaking the
   reliability promise.
   2. Run the closing procedure if a message is received on a stream before
   a data channel is ready to receive it.
   3. Don't even allow an out-of-band negotiated channel to be created
   after the SCTP association is established.
   4. Buffer these messages for up to X seconds (or up to X bytes), to be
   delivered to the data channel once it's created. Run the closing procedure
   if X is exceeded.

I'd vote for #2. Adding additional buffering logic seems like overkill if
this isn't a use case we really intended to support.

Corresponding webrtc-pc issue: https://github.com/w3c/webrtc-pc/issues/1879

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 31 May 2018 18:38:21 +0000

Hi,

As the data channel is realized as an SCTP stream, it sounds very weird that one would not be allowed to negotiate a data channel after the SCTP association has been established…

But, if a data channel is established out-of-band, shouldn’t the associated offer/answer transaction complete before the data channel is used?

Section 6.5 of draft-ietf-mmusic-data-channel-sdpneg says:

      “Each agent application MUST wait to send data until it has
        confirmation that the data channel at the peer is instantiated.”

In addition, the section describes when the offerer and answerer can consider that the data channel has been instantiated at the peer.

So, in my opinion any data that is sent before that could simply be dropped, which I guess would be alternative 5 :)

Regards,

Christer

From: rtcweb [mailto:[email-masked]] On Behalf Of Taylor Brandstetter
Sent: 31 May 2018 20:24
To: RTCWeb IETF <[email-masked]>
Subject: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels

One might expect that a "reliable" data channel is guaranteed to be, well, reliable. But in current implementations, the first messages may be lost if the application is negotiating the channels out-of-band, and creates the receiving channel too late.

Here's a fiddle that demonstrates this (happens with Chrome and Firefox): https://jsfiddle.net/o2m8tp20/

Normally this isn't an issue, because a typical application would create the out-of-band negotiated channels before the first offer/answer is complete, and thus before the SCTP association is established. Meaning that by the time a data channel is "open", it's guaranteed that the other peer has a corresponding channel.

But if for whatever reason, an application creates a data channel *after* the SCTP association is established, then it will instantly be "open" as soon as it's created. If a message is sent at this point, and it's received by the other peer before it's created its corresponding data channel, then the message will just be discarded.

  1.  Say "this is expected behavior" and document it better, breaking the reliability promise.
  2.  Run the closing procedure if a message is received on a stream before a data channel is ready to receive it.
  3.  Don't even allow an out-of-band negotiated channel to be created after the SCTP association is established.
  4.  Buffer these messages for up to X seconds (or up to X bytes), to be delivered to the data channel once it's created. Run the closing procedure if X is exceeded.
I'd vote for #2. Adding additional buffering logic seems like overkill if this isn't a use case we really intended to support.

---

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 31 May 2018 12:30:04 -0700

>
> As the data channel is realized as an SCTP stream, it sounds very weird
> that one would not be allowed to negotiate a data channel after the SCTP
> association has been established…
>

You can, using in-band negotiation. I'm only talking about out-of-band
negotiation, where typically an application will create the data channel
immediately after creating the PeerConnection.

Section 6.5 of draft-ietf-mmusic-data-channel-sdpneg says...

WebRTC doesn't use this, though. WebRTC data channels are established
either in-band, using draft-ietf-rtcweb-data-protocol, or out-of-band,
which is completely up to the application and doesn't involve SDP.

On Thu, May 31, 2018 at 11:38 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
>
>
> As the data channel is realized as an SCTP stream, it sounds very weird
> that one would not be allowed to negotiate a data channel after the SCTP
> association has been established…
>
>
>
> But, if a data channel is established out-of-band, shouldn’t the
> associated offer/answer transaction complete before the data channel is
> used?
>
>
>
> In addition, the section describes when the offerer and answerer can
> consider that the data channel has been instantiated at the peer.
>
>
>
> So, in my opinion any data that is sent before that could simply be
> dropped, which I guess would be alternative 5 :)
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* rtcweb [mailto:[email-masked]] *On Behalf Of *Taylor
> Brandstetter
> *Sent:* 31 May 2018 20:24
> *To:* RTCWeb IETF <[email-masked]>
> *Subject:* [rtcweb] Possible to lose initial messages sent by reliable,
> out-of-band negotiated data channels
>
>
>
>    2. Run the closing procedure if a message is received on a stream
>    before a data channel is ready to receive it.
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>
>

---

From: Lennart Grahl <[email-masked]>
Date: Fri, 1 Jun 2018 00:52:26 +0200

Hi,

I'm not sure yet going for anything but 4. is a good idea but this is 
just a gut feeling. If it has to be any of the first three options, I 
would want it to be 3. on the sender side and 2. on the receiver side 
because I very much prefer APIs that fail explicitly rather than implicitly.

Cheers
Lennart

---

From: Justin Uberti <[email-masked]>
Date: Thu, 31 May 2018 17:10:49 -0700

#2 seems like the least bad option, but it's going to be very difficult to
debug without additional information regarding why the close occurred.

On Thu, May 31, 2018 at 3:52 PM Lennart Grahl <[email-masked]>
wrote:

> > Corresponding webrtc-pc issue:
> https://github.com/w3c/webrtc-pc/issues/1879
> >
> >
> >

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Jun 2018 03:48:42 +0000

Hi,

No matter what out-of-band protocol you use for opening a data channel, it needs to provide some kind of indication that the peer is ready - and that the peer accepts the data channel to begin with.

Regards,

Christer

Sent from my iPhone

On 31 May 2018, at 22.30, Taylor Brandstetter <[email-masked]<mailto:[email-masked]>> wrote:

You can, using in-band negotiation. I'm only talking about out-of-band negotiation, where typically an application will create the data channel immediately after creating the PeerConnection.

WebRTC doesn't use this, though. WebRTC data channels are established either in-band, using draft-ietf-rtcweb-data-protocol, or out-of-band, which is completely up to the application and doesn't involve SDP.

On Thu, May 31, 2018 at 11:38 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: rtcweb [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Taylor Brandstetter
Sent: 31 May 2018 20:24
To: RTCWeb IETF <[email-masked]<mailto:[email-masked]>>
Subject: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels

_______________________________________________
rtcweb mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/rtcweb