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

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

On 31.05.2018 20:24, Taylor Brandstetter 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.
> 
> Corresponding webrtc-pc issue: https://github.com/w3c/webrtc-pc/issues/1879
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 