Re: [rtcweb] Data Channels Proposal: Now in Internet Draft Form

[Randell Jesup <[e-mail]>]

On 2/18/2013 12:51 PM, Martin Thomson wrote:
> I think that we're actually at the point where the involved parties
> each understand each other's positions.  Now comes the time to provide
> everyone else with a coherent proposal that they can evaluate.
>
> http://tools.ietf.org/html/draft-thomson-rtcweb-data-00
>
> This is intended as an alternative to the mechanisms in
> draft-ietf-rtcweb-data-channel.  It is also intended to render
> draft-jesup-rtcweb-data-protocol unnecessary.  That is, of course, as
> long as it meets with the approval of the working group.

Thanks for suggesting something concrete.  It really helps in helping 
get to the heart of the arguments.  I'd love to see one from the people 
who advocated pure-SDP in the room.  (or even an argument in favor of 
their position).

Ok, differences as I see them from draft-ietf-rtcweb-data-channel/etc, 
and comments:

*tl;dr:***I believe this actually ends up with more total complexity, 
especially in terms of the API presented to users/JS code, with little 
or no practical win in usecases or reduction in total code.   It feels 
at times like it's optimizing for some unspoken legacy SCTP application, 
or that it's a general preference to using it like raw SCTP and all else 
(negotiation, etc) is merely to satisfy (mostly) the W3's requirements.  
("If you care about consistency...")


*1. Requirements:*
Differences:
Your draft attempts to make virtually all feasible SCTP features visible 
to the application.  The current draft does not, and provides a limited 
set of features that are static per-channel.

Comments:
"The ability to use as many SCTP features as possible" - your draft 
certainly attempts to provide that, but that was generally rejected as a 
requirement in the past.  Exposing those features (even if they exist in 
SCTP) has a cost, both in API complexity and in testing. If I make 
per-packet markings visible, I need to build tests for all those fun 
edge cases.  One (of several) arguments was that if you need a different 
set of per-packet features, you can use a channel with different 
characteristics.  The actual use-cases for per-packet marking seem 
unlikely to be widely needed given access to multiple channels.  Another 
was that the more complexity exposed, the more complex the mental model 
and understanding of the underlying network protocol characteristics 
needed by the JS programmer.

If this is to be a requirement, it should be tied to some likely usecase 
we've defined or we expect this to be used for.  Are you adding new 
usecases?  If so, please disclose them, as no existing usecase requires 
what you've added here I believe.

*2. Overview:*
Differences:
Your draft ties Channels in a 1-1 mapping to specific stream numbers 
which are exposed.  The current draft ties them to pairs of streams 
(hidden), which may or may not be identical in number.

Your draft gives 3 ways channels can be created, basically telling it "I 
want you to make an offer including it", "I got an offer including it", 
and by messages "just arriving" on unused channels. The current draft 
(assuming 0 RTT setup) has two ways: createDataChannel() on one end, and 
onDataChannel on the other.

Your draft has ways where race conditions can cause channel creation 
failure, or if the other side rejects, etc.  The current draft only 
really can fail due to the association failing or a failure to increase 
the number of streams.

Comments:
It's a bit misleading to state the properties aren't per-message, since 
later you say you can change them per-message.  This is largely 
therefore an optimization to reduce typing/verbiage.  This does as you 
say enable you to use common code for websockets and this.

There are some significant missing pieces to the SDP negotiation part, 
at least at the W3 layer (which I realize this draft isn't, but we need 
to consider it in our design).  Unlike media, we don't have good ways to 
extract the datachannels offered/etc; the best I can think of would be 
to create all the datachannels offered on setRemoteDescription and fire 
events for them, and in response to the event if you want to reject it 
close() the stream before createAnswer.  But this is tricky, since all 
the onXXXX's are async and so when do you call createAnswer?  This seems 
an unspecified and thorny bit of JS API to define.  Doable, sure, but 
considerable complexity and increased async-ness for minimal gain (IMO).

I seriously dislike "it may fail if the other side used the channel".  
Why create such error paths and ways to break your app when there's no 
need to?  Is this needed for interfacing with some sort of legacy system?

*3. (In)consistent Properties*
Differences:
Your draft allows non-SDP-negotiated channels to have inconsistent 
properties.  The current draft does not.

Comments:
You could say properties are irrelevant since you can change them for 
each message; therefore they only matter if they're set and then the 
channel exposed to code that simply takes the properties for granted.

This means that to emulate a WebSockets channel, you'd need to (likely) 
negotiate it in SDP (especially given the label and protocol fields).

I don't see how apparently raw SS7 intererop is involved here.  Is this 
a new usecase?

How is this better for the application than the current draft (assuming 
0 RTT setup)?

*3.1 Negotiation*
Differences:
In your draft, properties can be offer/answer negotiated.  In the 
current draft, all properties are declarative; there is no negotiation 
over the properties.

Comments:
If you actually want to offer/answer over the properties you need to 
define all the O/A semantics, and then how to surface those to the app.  
This adds a lot of edge and error cases to deal with unless you define 
that no actual negotiation occurs.  You can punt and say all that is the 
apps business, but then you're back a "bad days" case having the app 
parse SDP, etc.

What are we gaining in practice here?  What usecase will use actual 
negotiation here, or is it just a way to implement consistent 
declarative properties?  (And there are still edge/error cases to deal 
with and at least ignore).

The current draft keeps things simple since there's no penalty really 
for setting up a channel you're not interested in - if you don't want 
it, just call "newchannel.close()".

*3.2 Dealing with Mismatched Properties*
Differences:
N/A (in the current draft this can't happen)

Comments:
There's a bunch here to deal with and describe what happens if the app 
uses a stream before or during negotiation/etc.  None of this is 
relevant in the current draft (and the API user doesn't have to 
understand all this).
*
**4. Available Data Channel Properties*
Differences:
Your draft specs a full set of possible SCTP properties and makes all 
but streamId mutable at any time.  The current draft has a much smaller 
set of properties (label, protocol, reliable, ordered, readystate, 
bufferedamount, binarytype). Only binarytype is mutable.  The only ones 
added vs WebSockets are reliable and ordered.

*5. SDP Format*
Differences:
Like what I proposed for the "1.5 RTT init SDP shortcut" in Boston, you 
have to specify each channel and all the properties.  The current draft 
(using the 0-RTT proposal) only needs to specify the protocol and 
protocol-level options like default number of streams.

Comments:
If this is O/A, it has a similar set of issues to m-lines, though they 
can go away since they have a stream number attached.  But you have to 
include all active ones in each O/A exchange.    What happens if you 
mutated the properties on one side in order to do packet-by-packet 
option selection.  Does that mirror into SDP?  Does the other side then 
change?  Since changing them on one side doesn't generate a 
negotiation-needed, if you echo the changes you could get surprised when 
negotiations happen for other reasons.  If it's purely declarative and 
doesn't track changes, it's more doable, but what happens if one side 
removes a channel in the O/A?  And can the answerer in the initial 
exchange add channels?  If so, what does the offerer do; is this real 
negotiation? Does this trigger negotiation-needed?

The current draft's SDP (minus the per-channel stuff not needed with 
0-RTT) is very simple.

Side note: the syntax won't work as the SCTP/DTLS spec allows for 
multiple associations; people like Cullen and others have argued for 
that being allowed for the generic case of SCTP over DTLS (the SCTP SDP 
spec isn't *just* for DataChannels in WebRTC).  But it could be reworked 
into a syntax that would work closer the what I presented.

-- 
Randell Jesup
[e-mail]