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

[Lennart Grahl <[e-mail]>]

I would be fine with either Taylor's option 4) or Justin's option 2) by
raising an explicit error containing a stream ID. In the WebRTC spec, we
could then resolve this by adding an `error` event to the
`RTCSctpTransport` interface where the event would contain the stream ID
a message has been received on.

Cheers
Lennart

On 15.06.2018 18:28, Justin Uberti wrote:
> The key question is: what should the browser do if it gets a data channel
> message on a channel that it doesn't know about?
> 
> I believe the only realistic options are:
> 1) eat it (silent failure)
> 2) explode (noisy but imprecise failure)
> 
> 
> On Fri, Jun 15, 2018 at 9:18 AM Cullen Jennings <[e-mail]> wrote:
> 
>>
>> Can the browser take care of it from what it knows about setting up the
>> channel?
>>
>> On Jun 13, 2018, at 4:48 PM, Taylor Brandstetter <[e-mail]>
>> wrote:
>>
>> 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.
>>
>> 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
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>