Re: [rtcweb] Data Channel Negotiation

Hi Martin,

just a few comments/questions in-line.

Best regards
Michael

On Feb 7, 2013, at 12:22 PM, Martin Thomson wrote:

> 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.
The signaling channel might have a different RTT than the peer to peer
connections. So you prefer to do take always the signaling channel.
Taking down a data channel is not signaled via SDP, right?

How do you handle a shortage in the number of streams? How do you
handle collisions if both sides want to open a data channel and
chose the same streams?
> 
> ==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
There is also a limitation of lifetime in milli seconds.
> 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.
So basically a data channel is not symmetric anymore. Do you consider
it bidirectional or unidirectional?
> 
> 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
If you consider a data channel to be bidirectional, what makes sure
that a stream for the backwards direction is available? How do you
now the pairing?
> 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
From an SCTP point of view: A receiver doesn't know that a particular
user message was sent reliable or not until it gets a FORWARD-TSN
chunk...
> 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.
I guess most of this comes down to the question of uni-/bi-directional...
> 
> 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
Not sure why you refer to RFC 4920... RFC 4960 (SCTP) doesn't have such
a limit.
> 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.
Going down this road: Do you consider data channels as abstractions
of SCTP streams? So uni-directional?
> 
> ===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.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 