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

[Martin Thomson <[e-mail]>]

None of what I suggest would change the API.  At most, it would have
removed the in-band handshake messages in exchange for loosening some
of the guarantees.  And I've been trained to value the deletion of
code highly.  That seemed like a good trade.

And timing?  It wasn't until you presented at the interim that I
realized just how little value the in-band handshake was adding.

In terms of the specifics of your fast open proposal, what do you do
with the message(s) that arrive on channels that you reject?  How does
this surface in the API?

I'll do a blow-by-blow on your points below, if you want to continue
the conversation.  If we're exchanging rhetoric bombs, I see little
point.

On 13 February 2013 02:36, Randell Jesup <[e-mail]> 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.
>
> --
> Randell Jesup
> [e-mail]
>
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb