Re: [rtcweb] Data Channel Negotiation and reopening of decisions

[Stefan Håkansson LK <[e-mail]>]

Without going into details, I'd like to support Randell's main message: 
we discussed this at length a long time ago, arrived at a solution that 
seem to support the use-cases, and even have implementations.

I haven't been convinced we should reopen all this again.

Stefan

On 2013-02-13 11:36, Randell Jesup wrote:
> 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.
>