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

Stefan Håkansson LK <> Wed, 13 February 2013 15:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E147521F86C5 for <>; Wed, 13 Feb 2013 07:13:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.323
X-Spam-Status: No, score=-5.323 tagged_above=-999 required=5 tests=[AWL=-0.574, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_111=0.6, J_CHICKENPOX_17=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CeTkwZvK2aVQ for <>; Wed, 13 Feb 2013 07:13:05 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2A55E21F86C2 for <>; Wed, 13 Feb 2013 07:13:04 -0800 (PST)
X-AuditID: c1b4fb25-b7f366d000004d10-65-511bad7f3065
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id B3.15.19728.F7DAB115; Wed, 13 Feb 2013 16:13:04 +0100 (CET)
Received: from [] ( by ( with Microsoft SMTP Server id; Wed, 13 Feb 2013 16:13:03 +0100
Message-ID: <>
Date: Wed, 13 Feb 2013 16:13:03 +0100
From: Stefan Håkansson LK <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrPJMWRmVeSWpSXmKPExsUyM+JvjW7DWulAg+ab3BZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoErY1Hff6aCey4VF681MjcwzjTvYuTkkBAwkVjR/44JwhaTuHBv PVsXIxeHkMBJRomNix6wQjhrGSUWTLvLClLFK6AtcfLuMiCbg4NFQFVi665YkDCbQKDE9f+/ wAaJCkRJvL/axAxRLihxcuYTFhBbREBYYuurXrAaYQFPiTk3j0It28gk8W3lD3aQBKeApsT5 n2cZQWxmAVuJC3Ous0DY8hLb384BGyokoCvx7vU91gmMArOQ7JiFpGUWkpYFjMyrGNlzEzNz 0suNNjECA+3glt+qOxjvnBM5xCjNwaIkzhvueiFASCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dU A6PJSYZ18k8cxG9k7i3fku2Wos/16bGT0H7fDUsLOlTEXz4+/XFlzI/oLzs1sp/4RVb0hH87 onT/z4knQQdvNbTw8HLul5po0bvggfOippk8Ova+3zjUmkWZN6/rtOPeX3BP1mX7VLvqOdbF OxRnt0/iu735ts9zLq+geYYPm5daWpo+uWWSvV2JpTgj0VCLuag4EQBKzQEZAgIAAA==
Subject: Re: [rtcweb] Data Channel Negotiation and reopening of decisions
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Feb 2013 15:13:08 -0000

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.


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 <> 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.