Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Randell Jesup <[e-mail]>]

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

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.

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.  With Open, only degenerate cases can 
cause more than a relatively small amount of data to be buffered.  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 -- 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.  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).

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


-- 
Randell Jesup
[e-mail]