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

[Paul Kyzivat <[e-mail]>]

On 2/11/14 1:06 PM, Peter Thatcher wrote:
> 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?

This seems reasonable to me.

	Thanks,
	Paul

> On Mon, Feb 10, 2014 at 5:10 PM, Paul Kyzivat <[e-mail]
> <mailto:[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] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/__listinfo/rtcweb
>         <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>
>     _________________________________________________
>     rtcweb mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/__listinfo/rtcweb
>     <https://www.ietf.org/mailman/listinfo/rtcweb>
>
>