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

[Justin Uberti <[e-mail]>]

I'm fine with that. We could advise implementations to log something to the
console when this happens.

On Tue, Jun 19, 2018 at 3:52 PM Taylor Brandstetter <deadbeef=
[e-mail]> wrote:

> It looks like we have 2 votes for "silently drop", 1 for "blow up" and 1
> for "behave nicely"...
>
> Since this behavior is already undefined, "silently drop" would certainly
> be the easiest; we can just add a note to the W3C spec:
> https://github.com/w3c/webrtc-pc/pull/1903
>
> On Sat, Jun 16, 2018 at 8:40 AM, Christer Holmberg <
> [e-mail]> wrote:
>
>> +1
>>
>> Regards,
>>
>> Christer
>>
>> -----Original Message-----
>> From: rtcweb [mailto:[e-mail]] On Behalf Of T H Panton
>> Sent: 15 June 2018 18:53
>> To: Lennart Grahl <[e-mail]>
>> Cc: [e-mail]
>> Subject: 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 <[e-mail]>
>> 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 <[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
>> >>
>> >
>> >
>> > _______________________________________________
>> > rtcweb mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>