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

[Cullen Jennings <[e-mail]>]

> On May 31, 2018, at 12:24 PM, Taylor Brandstetter <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/ <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:
> Say "this is expected behavior" and document it better, breaking the reliability promise.
> Run the closing procedure if a message is received on a stream before a data channel is ready to receive it.
> Don't even allow an out-of-band negotiated channel to be created after the SCTP association is established.
> 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