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

To be clear, I tried to keep the same numbering as Taylor - my #2 "explode"
option is the same as Taylor's #2 "run the closing procedure".

On Fri, Jun 15, 2018 at 9:44 AM 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
>