Re: [rtcweb] Data Channel Negotiation

[Randell Jesup <[e-mail]>]

On 2/8/2013 4:21 AM, Martin Thomson wrote:
> On 7 February 2013 10:49, Randell Jesup <[e-mail]> wrote:
>> The proposal I made yesterday (though I really didn't get a chance to
>> present it) was purely declarative in the SDP (the mixed case I proposed).
>> They were stand-ins for the Open in-band messages and carried the same
>> declarative info.
> The difference, from what I saw, was that the declarations in your
> examples showed stream 1 in the offer and no stream 1 in the answer.
> This would require that stream 1 appear in the answer with the
> attributes that the answerer had assigned (which we would require to
> be the same as the offerer, unless the answerer side had already had
> created a DataChannel).

As I mentioned, it was purely declarative (no response/negotiation), 
which is why the return SDP doesn't have them.

If you were to extend this to work for renegotiations where glare is 
possible, you'd have to either wait for the renegotiation to finish, or 
use some even/odd sort of trick which was proposed way back when on the 
list.

>> This limit probably can be relaxed; Websockets allows IIRC 71-bit lengths
>> ...  just in case you need them.
> 63 bit.  A poor decision in my opinion, but we need to respect working
> group consensus.

Ah yes, you're correct, 63 bits (encoded in 71 bits).  So small!


My proposal:
>> I like (a lot) the declarative approach, and all the complications were due
>> to needing to fulfill glare considerations (now resolved by not requiring
>> resolving of label glare and not requiring bidirectional stream pairs have
>> the same number), and due to the requirement for websockets compatibility
>> with onOpen (and to not fire it until you have positive notification from
>> the other side). If you drop that last part, you have immediate declarative
>> 0-RTT opening time DataChannels.  I would propose keeping things simpler for
>> users and to use the wireline protocol for the declaration/response, and
>> avoid all the weirdnesses around labels, protocols and modes caused by
>> dropping it.
>>
>> I like your Layer 2, but with the wireline protocol previously speced.  It
>> gets you all the label/mode/etc sync stuff, and merely rules out option A
>> (or requires you to dedicate a control stream).
> If we have out-of-band negotiation, the only thing that the protocol
> needs is a type indicator (one bit).  Reserve the other 7 bits (or 254
> values) and we're done.  There is no benefit to the control messages.

Out-of-band negotiation means either:

a) SDP offer/answer (which in many cases will go via a central server, 
though it can go over an existing datachannel), min 1 RTT (perhaps 
1-RTT-through-server) plus SDP processing delay, and requires 
implementing error handling for cases where the answers and offers don't 
properly match up,

b) a single control stream, which works, but it adds complexity since 
SCTP doesn't make between-stream guarantees about delivery, so you have 
to either have a handshake on the control stream before sending data (1 
RTT at least), or you need to have methods in place to handle 
out-of-order control versus data delivery, or

c) application-implemented out-of-band negotiation, which just (IMHO) 
pushes the problem off onto the application without solving any problems 
for the general case.  In the (fairly common) app talking to another 
instance of itself or a "known" peer, the application could pre-define 
what streams/channels mean, if we surface the stream numbers to the API 
(this would be far closer to the old 'raw SCTP' proposals, which push a 
lot over onto the app). This would also make interoperating in 
federation cases considerably more complex.

The reason the current in-band protocol uses in-stream open messages is 
that this avoids any out-of-order delivery issues (they're marked as 
reliable-in-order).  If you relax the don't-send-until-onopen JS 
requirement (which is no work for the wireline protocol; it's already 
supported) and fire onopen immediately on createDataChannel or when a 
channel open comes in, you have 0-RTT startup, and you retain all the 
symmetry, label, protocol, etc that had been previously agreed to.  See 
my quoted proposal above.

Are there real usecases where the in-band Open and OpenResponse messages 
actually cause a usecase not to work?

-- 
Randell Jesup
[e-mail]