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

[Michael Tuexen <[e-mail]>]

On Feb 10, 2014, at 6:29 PM, Christer Holmberg <[e-mail]> wrote:

> 
> 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.
>>>>>> 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.
>>>>> 
>>>>> My point is that I don't want to end up with more than one channel.
>>>> And you won't, see above.
>>> 
>>> I am not sure I understand. What text do you refer to?
>> 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.
> 
> 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.
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.
> 
> 
>>>> 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.
>>> 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.
> 
> 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.
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
> 
> Regards,
> 
> Christer
> 
>