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

[Randell Jesup <[e-mail]>]

tl;dr: (though this post *is* shorter):


Speaking to a larger point: What use-case(s) or what advantage does this 
get which is not provided by the current draft?  What's the practical 
advantage of changing?  Is the current draft problematic to implement, 
or is the new proposal significantly easier to implement?  (BTW, I'll 
note the current draft does support 0-RTT with no changes).  Can the 
current draft be modified to address these issues?  How much does this 
affect the complexity of the interface and API for JS users?  For 
example, why do you believe there's a need at the application level for 
per-packet mutation of the channel properties, given one has a large 
number of channels available?  What's the use-case?

tl;dr of tl;dr: You're suggesting a change late in the process, please 
give a focused answer to "why?"

Thanks!

On 2/19/2013 2:43 PM, Martin Thomson wrote:
> On 18 February 2013 22:21, Randell Jesup <[e-mail]> wrote:
>> *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...")
> I'm sensitive to the (potential) need for CLUE to use these channels.
> An in-band protocol makes that difficult.

My understanding is that they were interested in using our DataChannels 
protocol.  They can run other protocols on other associations on the 
same DTLS link if they want.  I've heard no indications that the current 
draft would cause a problem for them.

> It does make M3UA implementation possible, as opposed to impossible.
> But yes, I'm fairly sure that the set of people who care about that
> sort of thing is very small, if not zero.  The legacy cases are for
> amusement value only.

Ok, good.

>> 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.
> Like sending packets with different properties?  Doesn't sound
> especially hard.  It might even make some test cases easier to write.

The test space is combinatorially larger, since there are issues like 
out-of-order before/after in-order to test, reliable before/after/mixed 
with partial/no reliability, etc.

However, one can ignore this and assume the SCTP stack works, and 
usually you'll be right.

>> *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 does expose stream numbers in SDP.  Neither proposal
> requires that application be aware of the numbers.

No, the 0-RTT proposal never puts anything in SDP except association 
startup options.  The SDP acceleration isn't needed if 
createDataChannel() is 0-RTT.  That's why 0-RTT is a very simple solution.

>> 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.
> That's a false comparison.  Stream adds can always fail in either
> proposal - there aren't an unlimited number of streams.  Either could
> raise the stream limit.  jesup-rtcweb-data-protocol assumes that this
> is always possible, which is not the case.

They can fail due to no streams, and if so the onError callback (JS) is 
fired for the channel, and it's moved into the "closed" state. Not a 
problem, and per the quote above "or a failure to increase the number of 
streams".  If that's not in the draft, it will be.

> This proposal doesn't permit rejecting of new channels, so I don't
> know how you inferred that.  You can close immediately, which should
> suffice.

Ok, but if it's negotiated in SDP, what if the SDP answer doesn't have 
your channel?  Seems like rejection to me (and an app could edit the SDP 
to do so).

> The real race condition is a glare case where both sides add the
> "same" stream. For this proposal, that's based on stream number; for
> your proposal, it's based on label.  I didn't see how
> jesup-rtcweb-data-protocol proposes to resolve the glare caused when
> two open requests pass in flight for the same label, but this proposal
> only cares if you are performing offer/answer negotiation and that
> glare problem is already solved.

Long ago it was agreed on the list to drop label-glare resolution 
entirely.  If both sides create a channel name "foo", then both sides 
have 2 channels named "foo" and it's up to the application to deal with it.

>> 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 see, if you wanted to reject a channel, how would you do it?  That's
> a problem in either proposal.  This is potentially far worse for your
> proposal.  I suspect that the only real option would be to
> setRemoteDescription(), which could populate pc.dataChannels[]
> immediately (and prior to firing the ondatachannel events).  Then you
> could investigate and close in a synchronous fashion.

Actually, and I think I mentioned this in the room in Boston and again 
on the list since a couple of times, if you want to reject just call 
close() on the stream after it's created.  From what you say, your 
proposal for SDP is similar: declarative; close() to reject after the 
fact (since close doesn't go through O/A!)  If you use SDP to represent 
channels, you have to handle effective rejection even if it's officially 
declarative.

>> 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?
> I think that you misread this one.  If I create channel 3 and then try
> to create another channel 3, then that should fail.  I assume that you
> don't permit two channels with the same label in your proposal either.

Actually the current draft does allow duplicate names, per above. Read 
section 6; you'll see there's no mention of processing on the labels on 
either side.


-- 
Randell Jesup
[e-mail]