Subject: [rtcweb] Data channel: Handling of packets on unknown channels

From: Harald Alvestrand <[email-masked]>
Date: Thu, 28 Jun 2018 13:30:06 +0200

In considering the datachannel API, we encountered one interesting race
condition:

A: <configure for datachannel>

A: CreateOffer(), SetLocalDescription(), send SDP

B: SetRemoteDescription, CreateAnswer, SetLocalDescription, send SDP

B: Configure an externally defined data channel, with #3249

B: Send a message on #3249

A: SetRemoteDescription

A: Wait a while (THE PAUSE)

A: Configure #3249

Now, if a message comes in to A on #3249 during THE PAUSE, what is the
implementation to do?

I studied draft-ietf-rtcweb-data-channel-13 for at least 3 minutes
before concluding that it doesn't say.

What I'd PREFER it to say is "these messages will be dropped on the
floor. Tough luck."

I would prefer it to say so explicitly.

Can we do this?

-- 
Surveillance is pervasive. Go Dark.

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 28 Jun 2018 14:51:24 +0200

> On 28. Jun 2018, at 13:30, Harald Alvestrand <[email-masked]> wrote:
> 
Isn't that some kind or error condition?

If that it true, one could apply:

   If a message with an unsupported PPID is received or some error
   condition related to the received message is detected by the receiver
   (for example, illegal ordering), the receiver SHOULD close the
   corresponding data channel.  This implies in particular that
   extensions using additional PPIDs can't be used without prior
   negotiation.

> I would prefer it to say so explicitly.
Not sure about the procedural thing... That ID is stuck in the RFC editor queue
for a long time...

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

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 28 Jun 2018 16:22:08 +0200

>    extensions using additional PPIDs can't be used without prior

The receiver can't close the datachannel if the datachannel doesn't
exist yet, so this doesn't work for that case.

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 28 Jun 2018 16:35:15 +0200

> On 28. Jun 2018, at 16:22, Harald Alvestrand <[email-masked]> wrote:
> 
I was assuming that the SCTP receives a user message on a stream. When
this message is delivered to its upper layer, doesn't this layer know
that there is no data channel? I would assume that this layer triggers
the stream reset procedure. I'm not saying that the user (for example
via a JS API) is involved... I'm more talking about implementing this
iside the browser... 

Best regards
Michael

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 28 Jun 2018 17:01:00 +0200

Den 28. juni 2018 16:35, skrev Michael Tuexen:
> iside the browser..

Exactly, it could close the stream, but it can't close the data channel
since it doesn't exist.

I think closing the stream would be a mistake, since that would make the
outcome about whether you end up with the datachannel or not racy;
discarding data will give you a working datachannel once A gets around
to configuring it.

---

From: Michael Tuexen <[email-masked]>
Date: Thu, 28 Jun 2018 17:19:01 +0200

> On 28. Jun 2018, at 17:01, Harald Alvestrand <[email-masked]> wrote:
> 
Well, I can run the procedure and the peer will get an indication that
something isn't working well.
> discarding data will give you a working datachannel once A gets around
But if the user configures a reliable data channel, the user does not
get the service that was required...

Best regards
Michael

---

From: Taylor Brandstetter <[email-masked]>
Date: Thu, 28 Jun 2018 10:38:29 -0700

Note that I started a thread about this last month:
https://mailarchive.ietf.org/arch/msg/rtcweb/lIuiu91_L2nOh935eAqifrs_ius

---

From: Justin Uberti <[email-masked]>
Date: Thu, 28 Jun 2018 20:57:18 -0700

Taylor is correct. In that thread, we agreed that the PeerConnection doc
should say "tough luck".