[rtcweb] Data Channel Negotiation

[Martin Thomson <[e-mail]>]

We're a fickle lot.  It seems that decisions can be unmade very easily.

In any case, I promised a concrete proposal.  Here it is.  Beware:
long post ahead.

This proposal is progressive, I think that the best option would be to
take all of it, but we could choose to not adopt the later parts.
I'll start with the basics.

==Layer 1

Negotiate all new data channels with SDP offer/answer.

As I understand it, the 1.5 round trip cost for in-band channel
creation was to prevent glare.  (Randell hinted that there might have
been something else that was SCTP-specific, but this appears to reduce
to a straightforward glare situation.)  Doing the negotiation in SDP
lets us use the glare mitigation mechanisms we have built into SDP, so
we save 0.5 round trips for every new channel.

This allows us to ditch the in-band signaling protocol almost entirely
(see Option B below).

Creating a new data channel triggers the onnegotiationneeded event.

==Layer 2

Zero round trip channel establishment

The only reason that we have for negotiation of each channel is to
provide a consistent set of characteristics for each channel.  The
peer that creates a channel decides the values for label,
retransmission count (0, n, infinite), and subprotocol.  If you don't
care about these values being consistent between peers, or you have
another means of ensuring consistency, you don't need to negotiate new
channels at all.

Here, we permit the use of additional channels immediately after
creation, without negotiation.  This has several advantages...and
ramifications.  And no real drawbacks.

Firstly, the arrival of a packet on a stream that is not negotiated
will require the creation of a data channel.  The properties of this
data channel will be largely unknown. The browser can possibly detect
that the channel is unreliable if the packet doesn't request
acknowledgement, but that's something I'm not 100% clear on for
partially reliable messages.  As a result, the browser will be
required to leave these properties undefined or generate default
values for them.

It's perfectly OK to have default or undefined values for label,
reliability and subprotocol as long as you let the application set new
values.  This allows for another advantage: applications can, if they
choose, set the reliability on a per-packet basis, consistent with all
other SCTP APIs, but setting the property before sending each packet.
This keeps the simplicity of the API design, ensures websocket
compatibility for those that need it, but it exposes more SCTP
capabilities to those that desire those features.

This does have consequences for negotiation: Values for label,
reliability and subprotocol need to be declarative in SDP, not
negotiated.  Both peers would be required to signal the values that
they are using for each stream.  This would allow for the fact that
peers could set different values for the same stream number, based on
whatever values are set on their data channel object.  In the general
case, it allows one peer to declare the use of a particular stream and
the other peer to not advertise anything on the matching stream.

This also makes the 'onopen' event useless for all but the first
channel.  It should fire immediately for any channel that is created
when the association is already active.

Receipt of a message on a channel that has not already been created
locally causes the following events, one after the other:
ondatachannel, onopen, onmessage.

In order to maintain the symmetrical usage pattern, and the
websockets-compatible usage pattern, we would then require several
things:
1. The browser MUST, by default, negotiate streams with values that
match any in an offer if it does not already have a data channel for
that stream number.  The browser MUST also create the corresponding
data channels.
2. Applications that require perfect channel symmetry need to
negotiate before using streams.
3. Applications that care about having their use of the API be
interchangeable with websockets need to wait for the 'onopen' event
before sending anything, lest they get errors when switching to
websockets.

On that last point: We could require that channels reject attempts to
send() prior to the onopen event being processed, but that is
unnecessarily mean.  Calling createDataChannel() followed immediately
by send() should be OK as long as the association is active.  Just
because you haven't processed the 'onopen', doesn't mean that you
should be prevented from using a perfectly usable channel.  Of course,
waiting for onopen would be safest in the general case, and many
applications would naturally do this, but I see no reason to constrain
usage patterns unnecessarily.

===Option A

Removing the in-band protocol makes the negotiation of the protocol
that layers on top of SCTP less crucial ... it makes negotiation of
the upper-layer protocol less crucial.  In the WebRTC case, we
probably don't need to negotiate 'webrtc-datachannel', we could even
let the application decide the value for that label.

Personally, I don't think that we need to surface API to enable
changing protocols.  However, it would be completely harmless in this
configuration for an application to change the protocol label to
something else by editing SDP, so that they could interoperate with a
peer that expected another protocol.  That would enable CLUE usage, or
BFCP, or whatever, as long as you can find someone who talks SCTP over
DTLS over UDP.

===Option B

The one remnant of the in-band protocol that remains is the parts that
apply to the data payloads.  The in-band protocol is required to
provide two features:
1. the ability to distinguish between textual data and binary data
2. the ability to send messages of arbitrary length

I am sorely tempted to suggest that the first feature can instead be
part of channel configuration, such that it is negotiated (with a
default of binary).  This would mean that negotiation is needed if you
want to use text and you can't handle the conversion of binary to
text.  (Sadly, this isn't made easy and the top answer at
stackoverflow doesn't work for UTF-8:
http://stackoverflow.com/questions/6965107/converting-between-strings-and-arraybuffers)

For the second, draft-jesup-rtcweb-data-protocol indicates that 2Gb is
the limit, but my reading of RFC 4920 indicates that there is no limit
to message size.  I'm far from expert in this area, but is it possible
that this is an implementation limitation rather than a protocol one?
Either way, I'm tempted to suggest that fragmentation can be pushed to
the application.

This would allow for direct access to SCTP, rather than an
encapsulated layer.  This is good for several reasons.  Firstly, we
don't need to specify a protocol at all.  We avoid all the arguments
about what byte goes where.  More importantly, it leaves the SCTP
clean, allowing WebRTC applications to use SCTP without ornamentation.

===Option C

If you care about reconciling the values for label, reliability, and
subprotocol, it might be necessary to surface the values declared by
your peer in the API.  You can get this information from the SDP, but
if you don't like the idea of SDP spelunking you have two choices:
provide an 'on(re)negotiated' event that carries the values declared
by the remote peer; or, provide read-only accessors for these.

I'm not certain that reconciliation of these values is important.
Applications can even build their own mechanisms if it is.  If we must
build more mechanisms, then I tend to favor the 'on(re)negotiated'
event.