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

With my very old SNMP hat on, I say 1) you silently drop it.

I'd also say that this indicates that the {negotiated:true, id:0} thing is 
a misfeature.

T.

> On 15 Jun 2018, at 17:44, Lennart Grahl <lennart.grahl@gmail.com> wrote:
> 
> 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 <fluffy@iii.ca> 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 <deadbeef@google.com>
>>> 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 <fluffy@iii.ca> wrote:
>>> 
>>>> 
>>>> 
>>>> On May 31, 2018, at 12:24 PM, Taylor Brandstetter <
>>>> deadbeef=40google.com@dmarc.ietf.org> 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
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>> 
>> 
>> 
>> 
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>> 
> 
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb