Re: [rtcweb] Data Channel Negotiation

[Martin Thomson <[e-mail]>]

On 11 February 2013, Michael Tuexen <[e-mail]> wrote:
> One important thing is that they tie the two outgoing streams together.
> Each side controls its outgoing streams.
> The other things are just declaring channel properties...

The binding between stream X in one direction and stream X in the
other is as strong - or as loose - as the application needs.  This is
a departure from what was previously specified, but I think that the
advantages (0 RTT establishment) outweigh the disadvantages.


>>> How do you handle a shortage in the number of streams? How do you
>>> handle collisions if both sides want to open a data channel and
>>> chose the same streams?
>>
>> A shortage is easy, createDataChannel can throw an exception.
>>
>> Collisions are also easy - if you care about consistency, then do an
>> offer/answer, which has inbuilt glare resolution.  If you don't care
>> about consistency, both sides can create and use channels without
>> having to agree on the details.  (That's mostly based on the stuff
>> below.
> However, *if* data channels are bidirectional (which they currently are),
> then you need to tie two streams together. This has to be done somehow.
> I'm wondering how you envision this without using SDP and without the
> data channel protocol...

The easiest way to tie two channels together is to use the stream
number.  That is what I was proposing.

(If stream numbers are used, then you don't even need to have a strong
uniqueness guarantee on the label.)

In the case that this is negotiated, then the guarantee is exactly the
same as the one provided previously.  Otherwise, it's a little less
strong.  If both sides create a channel at the same time, then they
could be bound together without any strong assurances about the exact
nature of the bidirectionality guarantee.  Now, I'm OK with that.  You
may not be.

> If we change to data channels being uni-directional, then most of
> the stuff done by the data channel protocol is not required... I agree
> with that conclusion.
> However, currently that the bi-directional.

The API would remain bi-directional.  In fact, the API would be
unchanged, except as it pertains to timing of channel use.  The
guarantees with respect to consistency would be weaker than what is
provided, depending (again) on that timing.

> Instead of "prevent sending the return message" which would one side
> waiting forever,

That presumes a lot.  Many protocols have one-way messages.

> I would prefer sending some sort of error message
> (which is currently not specified enough in the data channel protocol).

This also assumes that you have some channel upon which to end this
error message, plus a definition for the error message.  I'm looking
to have less protocol machinery, not more.

>> number of channels to the lower of the two stream limits.  I prefer
>> the latter.
> As long as you know this limit... But RFC 6525 allows you to increase the
> number of streams (unless the peer agrees to do so).

Negotiating stream limits up doesn't seem like a particularly likely
thing in this sort of environment.  That said, we probably need to
decide if this is a feature that we want to have available.  If it is
available, then this could be used in the case that the limits are
reached.

>> b. There is no guarantee that the other side hasn't already created a
>> data channel on the same number.  That's not a problem - you just end
>> up with asymmetry.
> This is a normal case with the current data channel protocol. The
> stream identifiers might not be the same in both directions.
> When testing with the current implementation in Firefox, this actually
> happens a lot.

Interesting.  I'd be interested in learning how this would be signaled
and what the advantages of this arrangement are.