[rtcweb] Data Channel Negotiation and reopening of decisions

[Randell Jesup <[e-mail]>]

A general note to start this:

We've been here before.  ALL of this has been argued over in great 
detail A YEAR AGO.  I'm sorry if some people were not involved at the 
time, and I'm fine with technical criticism of details of the solutions 
chosen.  However, while we did not have formal consensus calls (I 
think), there certainly was list (and in many cases room) consensus on 
these details, such as bidirectional channels and adding the WebSockets 
'protocol' ID at Atlanta in order to ease heterogeneous application 
interop for things like chat.

Sure, there were many options available to us.  We discussed them in 
great detail and chose a solution that was strongly patterned on 
WebSockets (and to good effect, from what I've seen in practice).  
Options like my original proposals for effectively "raw" unidirectional 
SCTP with SDP negotiation were firmly rejected in favor of bidirectional 
channels with low-overhead creation - and I agreed with the consensus on 
the list.

*Can* we reopen all of this?  Sure!  We *can* reopen ANYTHING (including 
consensus calls).  *Should* we?  No, if we ever want to make progress, 
unless there is some technical problem with the solution.  The details I 
was trying to resolve here and finalize were the outcome of conflicting 
requests to make small changes to channel creation from the Interim 
*last June*.  If people had issues with the general approach, they 
should have been presented then (or earlier on the list).

"Rough consensus and running code"?  We certainly had rough consensus a 
long time ago on most of this (and more IMO).  Running code?  We have a 
largely debugged implementation today in Firefox that's in-use in our 
Social API stuff, in 3D games, and other prototype applications.  We 
worked closely with Michael Tuexen, Randall Stewart and others to polish 
the open user-space SCTP library.

To be clear:  My revised proposal after the discussion in the room and 
on the list is to resolve the startup issues by firing onopen 
immediately and thus allowing 0-RTT opens, removing the need for special 
SDP parameters other than the m=application line and a=sctpmap line 
(which are needed to specify an SCTP/DTLS association, and are part of 
the existing MMUSIC draft).

I think we have a *workable* solution that addresses the end-user 
requirements and expectations, and is flexible enough to support complex 
future uses, and will allow for straightforward heterogeneous 
application interop.  Let's move on and make progress where we *haven't* 
been able to eliminate alternatives yet (or where they keep expanding 
instead of being pruned away).


On to the detailed response:

On 2/11/2013 2:54 PM, Martin Thomson wrote:
> On 9 February 2013 07:24, Randell Jesup <[e-mail]> wrote:
>
>> 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.
> If you want to resolve glare, then you use the mechanisms you already
> have for glare resolution.  Which, RFC 3264 defers to RFC 3261, which
> uses a fairly heavy-weight mechanism.  Keep in mind that you already
> need this if you are using offer-answer.  Use whatever mechanism you
> already have in place (I like the tie-breaker random number method
> myself).
>
> Or, you could stop worrying about glare and in those cases where glare
> is possible, allow the collision to proceed.
>
> This is an application choice.

Not unless you change the semantics of the JS API I believe.  If you're 
exposing glare to the application in some manner that's complexity for 
them to manage (and in a case that's hard for them to test).  It's easy 
to imagine applications making mistakes or ignoring the possibility here 
if it's exposed.

>> 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,
> This was my thought.  There is no need to reserve a channel for this
> purpose, that's just extra machinery.  Any app that wants the fast
> path for this will make their own.  And, the nice thing about that is
> that they can do this before setting up the session.

Sure, that's the standard "fast-path" solution.  It's still 1 RTT and a 
lot of processing, and blocks other renegotiations while it's in-flight 
(that's fairly minor, but it would block adding more channels during 
that RTT).  Remember RTT isn't always tens of milliseconds.  Sometimes 
you're on a satellite link with 500+ms of RTT, sometimes you're on the 
other side of the globe with 200+ms RTT, sometimes you're fighting 
congestion or bufferbloat (it happens, and some apps like this may be 
pure-data apps) and you have crazy RTT's like 1 second+.  And if you 
have a non-colocated TURN server (say AUS->AUS via TURN in the US) you 
can have a lot of RTT.  TURN will be expensive; do not expect every app 
to have fully geo-dispersed TURN networks!  However, these are largely 
nits - it's still min 1 RTT an heavy string processing.

>> Are there real usecases where the in-band Open and OpenResponse messages
>> actually cause a usecase not to work?
> Well, given that we need message type stuff, we already have to suffer
> some extra muck on top of the SCTP association.  Not many applications
> will survive that.

Ok, good - I couldn't see how that argument made sense.

> No, the real question is: what value do these messages actually add?
> What information do they convey that isn't already negotiated through
> other channels?

It's an alternative to negotiating it through other channels.  In the 
proposal I just made here on the list, it gets you consistency with 
WebSockets and bidirectional symmetric channels (both also doable by 
other methods like pure-SDP), and 0-RTT opens (not possible in SDP while 
retaining the first set of JS-API-level features).

> Starting a stream with a header that declares attributes for a stream
> sounds nice, but it's completely unnecessary in a vast number of
> cases.  For many cases, this is a case of the same piece of software
> talking to itself - it hardly cares.  In many other cases, negotiation
> of properties through SDP is perfectly sufficient.

Sure, many apps will have (when talking to themselves) a fixed set of 
channels set up at the start, which was what I was attempting to 
optimize given the W3 constraint to wait for a truly-acknowledged 
'onopen' ala WebSockets.  My alternative proposed here is to fire onopen 
immediately (since DataChannels are declarative) and allow 0-RTT opens, 
obviating the need the SDP enhancements presented at the meeting.

We already do have people querying if DataChannels could be used for 
things like GFC avoidance for things like proxied browsing, which (if 
it's doable, which I haven't verified but seems plausible if the user 
grants the app special permissions), which would imply a need for 
low-overhead channel creation.

> The only case I see for an in-band protocol is where you wish to
> invent some new protocol on this platform, and I can't really muster
> up that much enthusiasm for that.  It's far too heavily reliant on my
> imagination.  Even in those cases, my knowledge of existing SCTP usage
> patterns suggest that the properties that are sent in
> Open/OpenResponse messages are not that useful to have.  Many
> applications will use the same values for all new streams.

There are lots of applications I envision (such as games) that will want 
a small mix of reliable and unreliable (or partially-reliable) channels, 
and others that want a mix of priorities (which we haven't talked about 
much, but would allow specifying if a data channel should be higher or 
lower priority than media streams, and perhaps more granularity.  
Control information (low BW) may be higher, file transfer may be lower, 
for example.

-- 
Randell Jesup
[e-mail]