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

[Martin Thomson <[e-mail]>]

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.

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.

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

Sure, an implementation now likely has to track more state on a
per-message basis, rather than referencing a channel-global, but
that's really very minor.

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

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

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.

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.

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

I always imagined that this would happen for media as well, noting
that streams might be slightly more challenging than something that
has all the properties present in the SDP.

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

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

It doesn't matter how you create the channel.  You can emulate
WebSockets in a number of ways (I believe that the default values for
channels produce WebSockets-compatible properties.  If you want to
signal "protocol" (label isn't a WebSockets concept), then yes, a
round trip is needed.  You could run an offer/answer round, or your
own application-specific signaling.  That round trip could be after
creating the channel, depending on your application needs.

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

See above.  These little jokes keep me from going (more) batty.

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

I don't think that the assumption is valid, so I'm not sure the
question is either.

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

You don't have negotiation, sure.  I think that you just have
unresolved glare scenarios.

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

Given that the SDP is declarative, I don't see how this is
substantively different from your proposal.  The 1.5RTT one.

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

In practice, we are providing a service for applications that care
about property consistency.  This says, "Here, you need to do
offer/answer anyway.  As long as you are doing O/A, we can use that to
ensure that your data channels match up nicely."

> 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()".

I don't see how that is different, or relevant.

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

... and label.  That's new too.

I'm ok with having less flexibility with respect to reliability.  I
was only being complete for the first pass.

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

Yes, that's clearly the biggest difference between this and your 0-RTT
in-band proposal: where these extra bits are passed.

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

That's a good thing.  I believe in clear expressiveness over saving
bytes.  gzip exists so that we don't have to make bad compromises in
these trade-offs.

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

Good question.  I didn't put that in the draft in part because it's
API-stuff, in part because I forgot.

The current values for properties should appear in the SDP when it is
generated.  If the answerer doesn't have that channel, it is required
to create one with matching properties.  This is the entirety of the
negotiation that goes on.  If the answer already has a channel, it
doesn't change that local channel properties.  The answer includes the
properties that the answer has for the channel.  The offerer might
learn of channels from an answer, and consequently should pass a new
channel object with matching properties to the app.

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

Changing properties doesn't trigger the need for negotiation, sure,
but creating the channel does.  I can't imagine any scenario where the
outcome of changes is surprising.

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

Removal/rejection was something I didn't add.  On purpose.  Close the
channel if you don't want it.

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

Yes.  The offerer is expected to create a matching channel and pass it
to the app.

No, this is not "real" negotiation.  That's because negotiation of the
sort that is performed when selecting codecs is not required.

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

That's unfortunate.  I did make an explicit note about this
assumption.  BTW, my preferred solve is:

a=sctp-port:5000

...with all the negative consequences that implies.