Subject: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 10:07:15 +0000

Hi,

As is defined in the data channel protocol, an entity can send data once DATA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is received.

The draft also says that, if both endpoints send DATA_CHANNEL_OPEN at the same time, using different stream id values, the result may be TWO data channels, with data sent on both.

However, as is also indicated, the draft does not provide a mechanism to prevent/handle such glare situation.

I personally think there shall be a way to prevent such situation, or otherwise I'm sure we are going to end up with interoperability problems.

Couldn't we e.g. say that, by default, the DTLS client is responsible for sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it could even use both an even or odd stream id value.

Regards,

Christer

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 10 Feb 2014 11:17:04 +0100

On Feb 10, 2014, at 11:07 AM, Christer Holmberg <[email-masked]> wrote:

> I personally think there shall be a way to prevent such situation, or otherwise I’m sure we are going to end up with interoperability problems.
>  
> Couldn’t we e.g. say that, by default, the DTLS client is responsible for sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it could even use both an even or odd stream id value.
Section 4 reads:

   To avoid glare in opening Channels, each side MUST use either even or
   odd Streams when sending a DATA_CHANNEL_OPEN message.  The method
   used to determine which side uses odd or even is based on the
   underlying DTLS connection role when used in WebRTC, with the side
   acting as the DTLS client using even stream identifiers.

So there is no problem in setting up data channels.

This should not be confused by both sides setting up a data channel with
the same Label. This ends up in two data channels with the same label.
You can even create more data channels with the same label.

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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 10:21:55 +0000

Hi,
 
> This should not be confused by both sides setting up a data channel with the same Label. This ends up in two data channels with the same label.

My point is that I don't want to end up with more than one channel.

Regards,

Christer

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 10 Feb 2014 11:36:34 +0100

> My point is that I don't want to end up with more than one channel.
And you won't, see above. However, there is no mechanism to ensure
uniqueness for labels. The WebRTC API already allows one side
to create n data channels with the same label.

Best regards
Michael

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 11:31:58 +0000

Hi,

>>>  To avoid glare in opening Channels, each side MUST use either even 
>>> or  odd Streams when sending a DATA_CHANNEL_OPEN message.  The method  
> And you won't, see above. 

I am not sure I understand. What text do you refer to?

> However, there is no mechanism to ensure uniqueness for labels. The WebRTC API already allows one side to create n data channels with the same label.

I am not saying it should be forbidden to do so. But, for protocol X, I want to end up with ONE data channel between my peers.

If I end up with two data channels for protocol X, can I send data on whichever I want to? 

Regards,

Christer

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 10 Feb 2014 17:56:47 +0100

> I am not saying it should be forbidden to do so. But, for protocol X, I want to end up with ONE data channel between my peers.
Then only one side should create a data channel.
> If I end up with two data channels for protocol X, can I send data on whichever I want to? 
Sure. These would be two independent bidirectional data channels.

Best regards
Michael

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 17:29:57 +0000

Hi,

> acting as the DTLS client using even stream identifiers.

That part I understand.

But, this means that both endpoints may send DATA_CHANNEL_OPEN, for the same protocol, and THAT is what I would like to avoid. I don't want to have two bi-directional data channels for the same thing.

For that reason I suggested that we could also specify which endpoint is responsisble for sending DATA_CHANNEL_OPEN.

> Sure. These would be two independent bidirectional data channels.

Possible for the same protocol - and that is what I would want to avoid. I want to send my protocol X messages on one data channel, and I would like to receive the protocol X messages from my peer on the same data channel.

Now, one can of course solve this by reseting one of the data channels, but then the question is which endpoint should reset :)

Regards,

Christer

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 10 Feb 2014 20:08:32 +0100

> For that reason I suggested that we could also specify which endpoint is responsisble for sending DATA_CHANNEL_OPEN.
But what if the side not allowed to send DATA_CHANNEL_OPEN messages creates a data channel?
The JS API allows both sides to create data channels.
> Possible for the same protocol - and that is what I would want to avoid. I want to send my protocol X messages on one data channel, and I would like to receive the protocol X messages from my peer…
That is fine. Then you have two choices:
* Use the data channel (establishment) protocol and manage yourself that only
  on side creates a data channel.
* Don't use the data channel protocol and create the channel manually. You need
  to negotiate the parameters out of band.
> Now, one can of course solve this by reseting one of the data channels, but then the question is which endpoint should reset :)
You could always close the data channel with the lower stream id. Both sides can close it...

Best regards
Michael

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Feb 2014 20:10:07 -0500

You two guys are talking past one another.

Christer's point is that the *application" distributed between the two 
endpoints, needs a *single* instance of a channel for a particular 
application specific purpose. But the two ends are generally symmetric. 
There is no obvious choice of which side should create the channel. So 
how do we use the mechanism to achieve this result?

I think I can predict what Michael is going to say: it isn't a protocol 
issue - the two ends should negotiate this some other way. (In the 
normal rtcweb scenario, a *single* app in the middle can arrange for one 
side to do the open.)

This is a problem with a sip app - there is no middle, just two ends.

> Couldn’t we e.g. say that, by default, the DTLS client is responsible for sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it could even use both an even or odd stream id value.

That is a bad thing for data channel in general. But I suppose the app 
can choose to follow this rule if it wants for particular channels.

	Thanks,
	Paul

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 11 Feb 2014 10:06:05 -0800

I believe the API already gives you all the tools you need for this use
case.  Here's one way to create a data channel where both ends call
createDataChannel() at the same time, with no "middle":

1.  Both sides call createDataChannel() with the same label.
2.  If an endpoint ends up with two data channels with the same label,
close the one with the higher .id, and keep the one with the lower .id.

Now both sides will use the same channel, and you can pretend like the
other never existed.   If you're worried about data sent before this
process completes, either accept data on both channels for a while, or
don't send data until the process completes.

Is there any reason this would not work?

On Mon, Feb 10, 2014 at 5:10 PM, Paul Kyzivat <[email-masked]> wrote:

> There is no obvious choice of which side should create the channel. So how
> do we use the mechanism to achieve this result?
>
> issue - the two ends should negotiate this some other way. (In the normal
> rtcweb scenario, a *single* app in the middle can arrange for one side to
> do the open.)
>
>  Couldn’t we e.g. say that, by default, the DTLS client is responsible for
>> sending the DATA_CHANNEL_OPEN? Then there is no risk for glare, and it
>> could even use both an even or odd stream id value.
>>
>
> That is a bad thing for data channel in general. But I suppose the app can
> choose to follow this rule if it wants for particular channels.
>
>         Thanks,
>         Paul
>
>
>
>
>
>
>>  As is defined in the data channel protocol, an entity can send data
>>>>>>>> once DATA_CHANNEL_OPEN has been sent, before the associated
>>>>>>>> DATA_CHANNEL_ACK is received.
>>>>>>>>
>>>>>>>> The draft also says that, if both endpoints send DATA_CHANNEL_OPEN
>>>>>>>> at the same time, using different stream id values, the result may be TWO
>>>>>>>> data channels, with data sent on both.
>>>>>>>>
>>>>>>>> However, as is also indicated, the draft does not provide a
>>>>>>>> mechanism to prevent/handle such glare situation.
>>>>>>>>
>>>>>>>> I personally think there shall be a way to prevent such situation,
>>>>>>>> or otherwise I'm sure we are going to end up with interoperability problems.
>>>>>>>>
>>>>>>>> Couldn't we e.g. say that, by default, the DTLS client is
>>>>>>>> responsible for sending the DATA_CHANNEL_OPEN? Then there is no risk for
>>>>>>>> glare, and it could even use both an even or odd stream id value.
>>>>>>>>
>>>>>>> Section 4 reads:
>>>>>>>
>>>>>>> This should not be confused by both sides setting up a data channel
>>>>>>> with the same Label. This ends up in two data channels with the same label.
>> But, this means that both endpoints may send DATA_CHANNEL_OPEN, for the
>> same protocol, and THAT is what I would like to avoid. I don't want to have
>> two bi-directional data channels for the same thing.
>>
>> For that reason I suggested that we could also specify which endpoint is
>> responsisble for sending DATA_CHANNEL_OPEN.
>>
>>
>>  However, there is no mechanism to ensure uniqueness for labels. The
>>>>> WebRTC API already allows one side to create n data channels with the same
>>>>> label.
>>>>>
>>>>
>>>> I am not saying it should be forbidden to do so. But, for protocol X, I
>>>> want to end up with ONE data channel between my peers.
>> Possible for the same protocol - and that is what I would want to avoid.
>> I want to send my protocol X messages on one data channel, and I would like
>> to receive the protocol X messages from my peer on the same data channel.
>>
>> Now, one can of course solve this by reseting one of the data channels,
>> but then the question is which endpoint should reset :)
>>
>> Regards,
>>
>> Christer
>>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Feb 2014 18:22:52 +0000

Hi Peter,

> I believe the API already gives you all the tools you need for this use case.  Here's one way to create a data channel where both ends call createDataChannel() at the same time, with no "middle":
>

Or, with the same Protocol.

It is a little unclear to me what "label" really is. The data channel draft says it's a "name of the channel"...

> 2.  If an endpoint ends up with two data channels with the same label, close the one with the higher .id, and keep the one with the lower .id.

What is ".id"? Is it something API specific? Keep in mind that non-WebRTC clients may also use the data channel.

> Now both sides will use the same channel, and you can pretend like the other never existed.   If you're worried about data sent before this process completes, either accept data on both channels for a while, or don't send data until the process completes.
>

Assuming it's generic, and not API specific, I guess it could work. 

Also, as has been indicated, specific protocols can specify rules regarding who opens the channel.

I think it would be good to have some informative guidance text about this somewhere, e.g. in the Data Channel draft.

Regards,

Christer

Christer's point is that the *application" distributed between the two endpoints, needs a *single* instance of a channel for a particular application specific purpose. But the two ends are generally symmetric. There is no obvious choice of which side should create the channel. So how do we use the mechanism to achieve this result?

I think I can predict what Michael is going to say: it isn't a protocol issue - the two ends should negotiate this some other way. (In the normal rtcweb scenario, a *single* app in the middle can arrange for one side to do the open.)

That is a bad thing for data channel in general. But I suppose the app can choose to follow this rule if it wants for particular channels.

        Thanks,
        Paul

Hi,

That part I understand.

Regards,

Christer

---

From: Peter Thatcher <[email-masked]>
Date: Tue, 11 Feb 2014 10:32:41 -0800

On Tue, Feb 11, 2014 at 10:22 AM, Christer Holmberg <
[email-masked]> wrote:

> It is a little unclear to me what "label" really is. The data channel
> draft says it's a "name of the channel"...
>

​Label is whatever the JS  or native app chooses it to be.​  You can give
it whatever semantics you want.

> clients may also use the data channel.
In​
​
​ JS, it's this:
http://dev.w3.org/2011/webrtc/editor/webrtc.html#widl-RTCDataChannel-id

​On the wire, it's the SCTP SID.​
​

> Assuming it's generic, and not API specific, I guess it could work.
​​
​Yes, it's generic.  The logic is basically, "if you end up with two SIDs
with the same label, close the channel with the higher SID".  Applies to
any endpoint.​

> I think it would be good to have some informative guidance text about this
> somewhere, e.g. in the Data Channel draft.
>
> Regards,
>
> Christer
>
>
>
>
>
>
> As is defined in the data channel protocol, an entity can send data once
> DATA_CHANNEL_OPEN has been sent, before the associated DATA_CHANNEL_ACK is
> received.
>
> The draft also says that, if both endpoints send DATA_CHANNEL_OPEN at the
> same time, using different stream id values, the result may be TWO data
> channels, with data sent on both.
>
> I personally think there shall be a way to prevent such situation, or
> otherwise I'm sure we are going to end up with interoperability problems.
>
> Couldn't we e.g. say that, by default, the DTLS client is responsible for
> However, there is no mechanism to ensure uniqueness for labels. The WebRTC
> API already allows one side to create n data channels with the same label.
>
> Possible for the same protocol - and that is what I would want to avoid. I
> want to send my protocol X messages on one data channel, and I would like

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 11 Feb 2014 19:00:49 +0000

Hi Peter,

Thanks for your input. I was useful ☺

And,  again, I think it would be good to add some guidance to the data channel draft.

Regards,

Christer

From: Peter Thatcher [mailto:[email-masked]]
Sent: Tuesday, February 11, 2014 7:33 PM
To: Christer Holmberg
Cc: Paul Kyzivat; <[email-masked]>
Subject: Re: [rtcweb] Data Channel Protocol: Prevent DATA_CHANNEL_OPEN glare

On Tue, Feb 11, 2014 at 10:22 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Peter,

​Label is whatever the JS  or native app chooses it to be.​  You can give it whatever semantics you want.

In​
​
​ JS, it's this:

​​
​Yes, it's generic.  The logic is basically, "if you end up with two SIDs with the same label, close the channel with the higher SID".  Applies to any endpoint.​

Christer

On Mon, Feb 10, 2014 at 5:10 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:
You two guys are talking past one another.

        Thanks,
        Paul

Hi,

That part I understand.

Regards,

Christer

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

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 11 Feb 2014 22:51:38 -0500

> Is there any reason this would not work?

This seems reasonable to me.

	Thanks,
	Paul

>     Christer's point is that the *application" distributed between the
>     two endpoints, needs a *single* instance of a channel for a
>     particular application specific purpose. But the two ends are
>     generally symmetric. There is no obvious choice of which side should
>     create the channel. So how do we use the mechanism to achieve this
>     result?
>
>     I think I can predict what Michael is going to say: it isn't a
>     protocol issue - the two ends should negotiate this some other way.
>     (In the normal rtcweb scenario, a *single* app in the middle can
>     arrange for one side to do the open.)
>
>         Couldn’t we e.g. say that, by default, the DTLS client is
>         responsible for sending the DATA_CHANNEL_OPEN? Then there is no
>         risk for glare, and it could even use both an even or odd stream
>         id value.
>
>
>     That is a bad thing for data channel in general. But I suppose the
>     app can choose to follow this rule if it wants for particular channels.
>
>              Thanks,
>              Paul
>
>
>
>
>
>
>                                 DATA_CHANNEL_OPEN has been sent, before
>                                 the associated DATA_CHANNEL_ACK is received.
>
>                                 However, as is also indicated, the draft
>                                 does not provide a mechanism to
>                                 prevent/handle such glare situation.
>
>                                 I personally think there shall be a way
>                                 to prevent such situation, or otherwise
>                                 I'm sure we are going to end up with
>                                 interoperability problems.
>
>                                 sending the DATA_CHANNEL_OPEN? Then
>                                 there is no risk for glare, and it could
>                                 even use both an even or odd stream id
>                                 value.
>
>                             Section 4 reads:
>
>                             This should not be confused by both sides
>                             setting up a data channel with the same
>                             Label. This ends up in two data channels
>                             with the same label.
>         But, this means that both endpoints may send DATA_CHANNEL_OPEN,
>         for the same protocol, and THAT is what I would like to avoid. I
>         don't want to have two bi-directional data channels for the same
>         thing.
>
>         For that reason I suggested that we could also specify which
>         endpoint is responsisble for sending DATA_CHANNEL_OPEN.
>
>
>                     However, there is no mechanism to ensure uniqueness
>                     for labels. The WebRTC API already allows one side
>                 I am not saying it should be forbidden to do so. But,
>                 for protocol X, I want to end up with ONE data channel
>                 between my peers.
>         Possible for the same protocol - and that is what I would want
>         to avoid. I want to send my protocol X messages on one data
>         channel, and I would like to receive the protocol X messages
>         from my peer on the same data channel.
>
>         Now, one can of course solve this by reseting one of the data
>         channels, but then the question is which endpoint should reset :)
>
>         Regards,
>
>         Christer
>
>         _________________________________________________
>         rtcweb mailing list
>         [email-masked] <mailto:[email-masked]>
>         https://www.ietf.org/mailman/__listinfo/rtcweb
>         <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>
>     _________________________________________________
>     rtcweb mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>

---

From: "Makaraju, Maridi Raju (Raju)" <[email-masked]>
Date: Wed, 12 Feb 2014 18:51:20 +0000

>However, as is also indicated, the draft does not provide a mechanism to prevent/handle such glare >situation.

>I personally think there shall be a way to prevent such situation, or otherwise I'm sure we are going >to end up with interoperability problems.
[Raju] The whole discussion is about “Prevent DATA_CHANNEL_OPEN glare”. I don’t think we should call it a general “glare” situation. DCP just provides a way to open raw data channels with both sides using same stream id, that’s all. Rest of the semantics for tying a data channel to a particular use is completely defined by application. The “protocol” field itself is not sufficient to have uniqueness at the application level as there could be multiple data channels using the same protocol. MSRP application is an example where MSRP could be used for chat, file transfer etc. The label can be used by application to have uniqueness. But the smarts need to be in the application in general as when to open data channels and what do they mean? Some applications like MSRP do not need to know if the data channel sub-protocol+labels are unique or not. Other applications like gaming may have a need for one quique game control channel, opened by either side. To achieve this, the application needs to have a deterministic algorithm with either out-of-band signaling (could be using one of the data channels as master control channel by initiator) or by a simple “offerer opens the control channel”.

So, in summary I don’t think any specific notes are needed in DCP for this other than saying “it is upto the application to tie semantics of data channel use”, which I think is inherent by default.

-Raju