Subject: [rtcweb] Opening unordered data channel issue

From: Michael Tuexen <[email-masked]>
Date: Thu, 22 Aug 2013 17:52:06 +0200

Dear all,

at the last IETF in Berlin we discussed how to handle the opening of
unordered data channels (no matter wether reliable or not). The problem
to be handled is that it is possible that user messages arrive at the
receiver before the DATA_CHANNEL_OPEN message is received. The result
of the discussion at the meeting was that the best solution is that
the sender sends user messages also ordered (on unordered channels)
until there is an indication from the peer that the DATA_CHANNEL_OPEN
has been processed. This makes sure that the DATA_CHANNEL_OPEN message
is not received before user messages and therefore the above problem
is solved.

The open issue is, what the indication from the peer is. There were
two options discussed at the meeting and it was decided that Randall
Stewart and myself bring this to the list with the pros and cons
of the alternatives. So here are the two options:

(a) Use any user message sent from the peer as an indication.
(b) Use a new ACK message.

Arguments:
* Using (b) introduces a 2-way handshake for unordered data channels.
  However, it also works for data channels being used unidirectional.
* Using (a) stays with the 1-way handshake, but in case of
  data channels being used unidirectional you will not see the benefits
  of unordered delivery.

We had some discussions offline and think that using (b) is the
cleaner solution. Please note that this 2-way handshake is not
similar to the one we had some time ago. The ACK does not contain
any additional information and it does not introduce any delay.
You can send user data right after opening the data channel.

For consistency we would even propose to use this 2 way handshake
for ordered channels. It doesn't have any drawback and would mean
that we use the same handshake for all data channels.

So the proposed procedure for opening an arbitrary data channel is:
1) The opener sends a DATA_CHANNEL_OPEN message ordered and reliable.
2) The opener can start sending user data immediately.
   It will always be sent ordered, no matter whether the data channel
   is ordered or not.
3) The peer will send a DATA_CHANNEL_ACK message ordered and reliable
   in response to the DATA_CHANNEL_OPEN message.
4) After reception of the DATA_CHANNEL_ACK message,
   the opener will sent user messages unordered,
   if the data channel is unordered and ordered, if the
   data channel is ordered.

Any opinions?

Best regards
Michael

---

From: Justin Uberti <[email-masked]>
Date: Thu, 22 Aug 2013 10:12:38 -0700

I agree that b) is the cleanest choice. While this makes the handshake
2-way, it does not suffer from the performance issues that affected the
previous 2- and 3-way handshake proposals, since data can be sent
immediately without waiting for the ACK.

On Thu, Aug 22, 2013 at 8:52 AM, Michael Tuexen <
[email-masked]> wrote:

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

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 22 Aug 2013 18:24:02 +0000

On Aug 22, 2013, at 11:12 AM, Justin Uberti <[email-masked]> wrote:

> I agree that b) is the cleanest choice. While this makes the handshake 2-way, it does not suffer from the performance issues that affected the previous 2- and 3-way handshake proposals, since data can be sent immediately without waiting for the ACK.

+1

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 22 Aug 2013 11:27:59 -0700

I agree that b) is the better choice, of the two.

---

From: "Matthew Kaufman (SKYPE)" <[email-masked]>
Date: Thu, 22 Aug 2013 23:16:39 +0000

> Any opinions?

Use something other than SCTP so that you have transport semantics that don't cause issues like this.

Matthew Kaufman

(Sent from my iPhone)

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 22 Aug 2013 23:49:18 -0400

+1 for (b).

On Aug 22, 2013, at 1:12 PM, Justin Uberti <[email-masked]> wrote:

> On Thu, Aug 22, 2013 at 8:52 AM, Michael Tuexen <[email-masked]> wrote:
> Dear all,
>

---

From: Victor Pascual Avila <[email-masked]>
Date: Fri, 23 Aug 2013 12:40:44 +0200

I agree -- +1 for b)

On Thu, Aug 22, 2013 at 7:12 PM, Justin Uberti <[email-masked]> wrote:
> On Thu, Aug 22, 2013 at 8:52 AM, Michael Tuexen
> <[email-masked]> wrote:
>>
>> Dear all,
>>

---

From: Harald Alvestrand <[email-masked]>
Date: Fri, 23 Aug 2013 17:46:09 +0200

I like this solution (b). Let's Just Do It.

-- 
Surveillance is pervasive. Go Dark.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 23 Aug 2013 12:07:17 -0700

+1