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

From: Cullen Jennings <[email-masked]>
Date: Wed, 13 Jun 2018 14:32:55 -0600

> On May 31, 2018, at 12:24 PM, Taylor Brandstetter <deadbeef=[email-masked]> 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/ <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:
> Say "this is expected behavior" and document it better, breaking the reliability promise.
> Run the closing procedure if a message is received on a stream before a data channel is ready to receive it.
> Don't even allow an out-of-band negotiated channel to be created after the SCTP association is established.
> 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

---

From: Taylor Brandstetter <[email-masked]>
Date: Wed, 13 Jun 2018 15:48:15 -0700

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 <[email-masked]> wrote:

>
>
> On May 31, 2018, at 12:24 PM, Taylor Brandstetter <
> deadbeef=[email-masked]> 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.
>
>    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.
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 14 Jun 2018 06:09:13 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

On May 31, 2018, at 12:24 PM, Taylor Brandstetter <deadbeef=[email-masked]<mailto:deadbeef=[email-masked]>> wrote:

Here's a fiddle that demonstrates this (happens with Chrome and Firefox): https://jsfiddle.net/o2m8tp20/

  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.

---

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 14 Jun 2018 10:06:03 -0700

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 <
[email-masked]> 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
> 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
>
>
>
>
>
>> 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.
>>
>>    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.
>>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 15 Jun 2018 13:17:35 +0000

What happens if it doesn’t should be unspecified in my opinion. The important thing to point out is that the reliability of the data channel doesn’t apply until both peers have opened the data channel. How the peers inform each other about that is signaling protocol specific.

As a future extension , even if a data channel is negotiated out-of-band, we could define that an in-band handshake still takes place before any data is sent.

Regards,

Christer

Sent from my iPhone

On 14 Jun 2018, at 19.06, Taylor Brandstetter <[email-masked]<mailto:[email-masked]>> wrote:

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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 15 Jun 2018 10:17:49 -0600

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 <[email-masked]> wrote:
> 
> On Wed, Jun 13, 2018 at 1:32 PM, Cullen Jennings <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On May 31, 2018, at 12:24 PM, Taylor Brandstetter <deadbeef=[email-masked] <mailto:deadbeef=[email-masked]>> wrote:
>>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 15 Jun 2018 09:28:02 -0700

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 <[email-masked]> wrote:

> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Lennart Grahl <[email-masked]>
Date: Fri, 15 Jun 2018 18:44:18 +0200

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

---

From: T H Panton <[email-masked]>
Date: Fri, 15 Jun 2018 17:52:30 +0100

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 <[email-masked]> wrote:
>

---

From: Justin Uberti <[email-masked]>
Date: Fri, 15 Jun 2018 11:30:40 -0700

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 <[email-masked]>
wrote:

> >>> I lean toward something that just did not allow the  out-of-band
> channel
> >>> negotiation be used until it was set up.
> >>>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 16 Jun 2018 15:40:09 +0000

+1

Regards,

Christer 

-----Original Message-----
From: rtcweb [mailto:[email-masked]] On Behalf Of T H Panton
Sent: 15 June 2018 18:53
To: Lennart Grahl <[email-masked]>
Cc: [email-masked]
Subject: Re: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels

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

T.

> 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
> 
>> 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?
>> 
>>> On Jun 13, 2018, at 4:48 PM, Taylor Brandstetter 
>>> <[email-masked]>
>>> 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.
>>> 
>>>> 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.
>>>> 
>>>> 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.
>>>> 
>>>> I'd vote for #2. Adding additional buffering logic seems like 
>>>> overkill if this isn't a use case we really intended to support.
>>>> 
>>>> 
>>>> channel negotiation be used until it was set up.
>>>>

---

From: Taylor Brandstetter <[email-masked]>
Date: Tue, 19 Jun 2018 15:51:42 -0700

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

---

From: Justin Uberti <[email-masked]>
Date: Tue, 19 Jun 2018 16:57:51 -0700

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