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

[Christer Holmberg <[e-mail]>]

What happens if it doesn’t should be unspecified in my opinion. The important thing to point out is that the reliability of the data channel doesn’t apply until both peers have opened the data channel. How the peers inform each other about that is signaling protocol specific.

As a future extension , even if a data channel is negotiated out-of-band, we could define that an in-band handshake still takes place before any data is sent.

Regards,

Christer

Sent from my iPhone

On 14 Jun 2018, at 19.06, Taylor Brandstetter <[e-mail]<mailto:[e-mail]>> wrote:

So you're suggesting for the web app to just take care to avoid this? But the point of this thread is to decide what happens if it *doesn't*.

On Wed, Jun 13, 2018 at 11:09 PM, Christer Holmberg <[e-mail]<mailto:[e-mail]>> wrote:
Hi,

>It sounds like you and Christer are suggesting the same thing: "don't allow messages to be sent until you're sure the other peer has a channel to receive them". Except that there's no way for the WebRTC stack to know that, since these channels are not signaled in SDP or any in-band message.

Even if the Web app cannot tell the WebRTC stack when the peer has a data channel, the Web app can still control when it starts sending data on the data channel, can’t it?

Regards,

Christer





On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings <[e-mail]<mailto:[e-mail]>> wrote:


On May 31, 2018, at 12:24 PM, Taylor Brandstetter <deadbeef=[e-mail]<mailto:deadbeef=[e-mail]>> wrote:

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.

I lean toward something that just did not allow the  out-of-band channel negotiation be used until it was set up.

But whatever we do, not option 1