Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Matthew Kaufman <[e-mail]>]

On 4/25/2013 2:42 PM, Randell Jesup wrote:
> On 4/25/2013 5:10 PM, Cullen Jennings (fluffy) wrote:
>> So with my co-chair hat on here…
>>
>> It seems we have been around the need for OPEN several times and have 
>> come to consensus on it in the past. Can someone please:
>>
>> 1) summarize the arguments that in the past that lead us to think we 
>> need OPEN
>
> The Open message has some important and useful properties:
>
> 1) It's easier to work with.  JS isn't an ideal language for writing 
> network protocols, especially for non-network-programmers (i.e. a 
> large portion of the expected developer community).  Open makes it 
> really easy for a developer to get the type of bidirectional stream 
> them want with little fuss, and in a manner that maps easily to APIs 
> they're already used to (e.g. WebSockets).  In many cases the label 
> field will avoid the JS programmer having to build their own 
> mini-protocol to identify their channels (and this is especially 
> painful for them if it's an unreliable channel).

Easier how? The initiating side needs to create their object without the 
benefit of the contents of an open message. If a JS developer isn't 
smart enough to set up the channel parameters they want at the 
initiating end, then there's nothing we can do for them. There's then 
several ways forward after that, including "the other side does the same 
thing to create their end" (my preference) and "the parameters are 
transported using the existing SDP O/A mechanism to the far end" 
(generally how the WG solves this kind of problem).

As far as I can tell, the one useful thing in the OPEN message is the 
label (as I pointed out in my very first inquiry about why anyone 
thought it was needed), and yet the label is allowed to be null, so in 
that case how can it be helpful?

>
> 2) It makes it possible to have different applications exchange data, 
> by having an IANA-registered protocol name, like WebSockets (and there 
> was strong agreement on it's being needed for that at Atlanta.)  With 
> external-negotiation-only, it would be very hard for different apps to 
> interoperate, since they'd need to agree on negotiation protocols as 
> well, which are likely to be highly divergent between apps.

If we went with "negotiated via the SDP O/A mechanism" then we could go 
to our favorite SDP-defining WG and have a negotiation protocol that is 
standardized, so not divergent at all between apps.

>
> 3) The Open message, being in-channel, reliable and in-order, makes 
> the issue that was the genesis of this thread (what to do with data 
> that arrives unexpectedly) simpler.

I disagree. It increases the number of possible states... there's cases 
where the OPEN message arrives but the application doesn't want to be 
receiving that data, and the cases where the OPEN message doesn't arrive 
but the application does want the data that is already arriving. Both of 
those states don't exist if there's no OPEN message.

> With Open, only degenerate cases can cause more than a relatively 
> small amount of data to be buffered.

Sure, but those degenerate cases occur many times per day on the real 
Internet.

> With external notification, the external negotiation channel can fail 
> (or be very slow), or the app can have a bug and fail to install the 
> negotiated values, leading to larger or unbounded buffering 
> requirements - or you punt the problem to the application by 
> delivering the data, but the application is facing the same conundrum 
> of buffer it or throw it away.
>
>> 2) sketch out the range of possible solutions to deal with unexpected 
>> data before the OPEN
>
>
> The issue exists regardless of whether Open is used or external 
> negotiation (and in fact is much simpler for Open).
>
> *tl;dr: *I'm ok with any setting of maximum sizes and/or times that 
> would not adversely impact temporary buffering for normal cases with 
> Open of unordered channels.  This is option C below.  I also would be 
> ok with B, but I realize others may not be.
>
> Regardless of supporting Open or not, any external negotiation of 
> dynamic channels must use one of these:
>
> A) a 2-or-3-way handshake so the sender knows the receiver is ready to 
> receive the data on the specified channel before sending it, or
>
> B) unbounded buffering of data if the external negotiation messages 
> are delayed (again, what we're discussing in this thread), or
>
> C) bounded buffering of data (bounded by time, size or both), with 
> data being dropped and the channel closed if the limits are exceeded, or
>
> D) deliver unexpected data to the application, which will do .... I 
> don't know what with it.
>
> For (D), the application will likely drop it on the floor (leading to 
> hard-to-test-for problems if the channel is later configured by Open 
> or external negotiation), or buffer it waiting for the channel to open.
>
> Supporting Open or not has little bearing on these scenarios

So if that's true, then why do we need it?

> -- and in fact, since Open is in-channel, reliable, and ordered, it 
> reduces the problem set (when Open is used) to only unordered channels 
> (in ordered channels Open will always be first).
>
> Buffering unexpected data on channels (options B or C) is useful. It 
> means that in the external negotiation case, one side asking for a new 
> channel to open by some private means doesn't need to wait to start 
> sending data on that channel.

Of course this is different from the TCP model, where the buffering 
happens at the *sender* until the handshake is complete.

The problem here is that we have an existing mechanism inside of SCTP 
and then we're adding another layer on top of that which is neither 
inside SCTP (where it probably belongs) or under the application 
developer's control (where I'd like to see it, if the data transport 
protocol can't have it), and this layer conflicts with what both of 
those might be doing.

> Note that with external negotiation (possibly on a non p2p path, like 
> via signaling), the receiver might not know what to install for a 
> short while, especially if there's a routing issue or server issue 
> (not a problem that happens with Open).

Which is fine if the sender doesn't start sending (like TCP). Or if the 
transport protocol itself handles the delivery of the channel metadata. 
(Which is what SCTP, or whatever transport we choose for RTCWEB, should 
do) then you just handle the label and whatever other metadata the 
receiver would like to know at that layer.

>
> Since normal Open cases have very little chance of triggering this 
> problem (triggering buffering), some arbitrary size limit seems 
> reasonable (option C).  Often in network protocols there are small 
> buffers (4, 16, 64KB).  I prefer a larger value of say 256KB so that 
> apps using external negotiation can just send largish data immediately 
> - and note: actually buffering data is still an unlikely occurrence 
> even in most external negotiation cases.  If people want to bikeshed 
> on the buffersize or timeout, that's fine. ;-)
>
> Also, external negotiation is the only case where more than a trivial 
> amount of data can "pile up" in the buffer waiting for the receiving 
> side to finish it's side of the negotiation (i.e. if your external 
> negotiation channel fails or the app has a brain fart).
>
>

Another great argument for having this negotiation happen within the 
transport itself.

Matthew Kaufman