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

Hi,

No matter what out-of-band protocol you use for opening a data channel, it needs to provide some kind of indication that the peer is ready - and that the peer accepts the data channel to begin with.

Regards,

Christer

Sent from my iPhone

On 31 May 2018, at 22.30, Taylor Brandstetter <deadbeef@google.com<mailto:deadbeef@google.com>> wrote:

As the data channel is realized as an SCTP stream, it sounds very weird that one would not be allowed to negotiate a data channel after the SCTP association has been established…

You can, using in-band negotiation. I'm only talking about out-of-band negotiation, where typically an application will create the data channel immediately after creating the PeerConnection.

Section 6.5 of draft-ietf-mmusic-data-channel-sdpneg says...

WebRTC doesn't use this, though. WebRTC data channels are established either in-band, using draft-ietf-rtcweb-data-protocol, or out-of-band, which is completely up to the application and doesn't involve SDP.

On Thu, May 31, 2018 at 11:38 AM, Christer Holmberg <christer.holmberg@ericsson.com<mailto:christer.holmberg@ericsson.com>> wrote:
Hi,

As the data channel is realized as an SCTP stream, it sounds very weird that one would not be allowed to negotiate a data channel after the SCTP association has been established…

But, if a data channel is established out-of-band, shouldn’t the associated offer/answer transaction complete before the data channel is used?

Section 6.5 of draft-ietf-mmusic-data-channel-sdpneg says:

      “Each agent application MUST wait to send data until it has
        confirmation that the data channel at the peer is instantiated.”

In addition, the section describes when the offerer and answerer can consider that the data channel has been instantiated at the peer.

So, in my opinion any data that is sent before that could simply be dropped, which I guess would be alternative 5 :)

Regards,

Christer

From: rtcweb [mailto:rtcweb-bounces@ietf.org<mailto:rtcweb-bounces@ietf.org>] On Behalf Of Taylor Brandstetter
Sent: 31 May 2018 20:24
To: RTCWeb IETF <rtcweb@ietf.org<mailto:rtcweb@ietf.org>>
Subject: [rtcweb] Possible to lose initial messages sent by reliable, out-of-band negotiated data channels

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.

Corresponding webrtc-pc issue: https://github.com/w3c/webrtc-pc/issues/1879

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org<mailto:rtcweb@ietf.org>
https://www.ietf.org/mailman/listinfo/rtcweb