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

[Taylor Brandstetter <[e-mail]>]

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]> 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]> wrote:
>
>>
>>
>> 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/
>>
>> 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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>