Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Cullen Jennings <[e-mail]>]

Thank you summarizing all this. 

On Apr 25, 2013, at 3:42 PM, Randell Jesup <[e-mail]> 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).
> 
> 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]
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb