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

[Peter Thatcher <[e-mail]>]

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 <[e-mail]> wrote:

> 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.
>
>
> Previously Christer said:
>
>  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
>
>
>
>
>
>
> On 2/10/14 12:29 PM, Christer Holmberg 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.
>>
>>
>>  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.
>>
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>