Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Michael Tuexen <[e-mail]>]

On Apr 23, 2013, at 8:17 PM, Peter Thatcher wrote:

> Based on feedback, it sounds like we're basically narrowing this down to "buffer for a while and then fire an error locally without giving the data to JS, and close the stream so the remote side knows".  That sounds pretty good to me.
Does the remote side should get any indication that the sent messages are dropped and not
being delivered?

Best regards
Michael
> 
> 
> On Fri, Apr 19, 2013 at 12:12 PM, Peter Thatcher <[e-mail]> wrote:
> I like all the discussion, but I feel like we need to get back to the question and what options we have.  The question: "what does the browser do with unexpected data (before an open of an unregistered sid)?"
> 
> 1. Buffer forever without limits:  Randell thinks it's OK to buffer forever without limits.  Martin disagrees.  I disagree (I agree with Martin).
> 2. Buffer with limits, and then:
>   a.  Hand an error to JS saying "got some data for a data channel, but an OPEN never came" WITHOUT providing the data to JS: Harald likes this.  I'm OK with this.
>   b.  Hand an error to JS saying "got some data for a data channel, but an OPEN never came" WITH providing the data: I like this better, since I don't see a reason not to give JS the data.  
>   c.  Fire .ondatachannel: This is what I was was originally thinking, but I understand the downsides mentioned, and would be happy with (b) instead.
>  
> 
> Right now, it seems like 2a or 2b is our best options, mixed with resetting the stream.  In other words, if I'm a browser, I'd do something like:
> 
> function handle_data(sid, data) {
>   if (is_open_message(data)) {
>     var info = get_stream_info(data)
>     var buffered_data = clear_buffer(sid)
>     fire_ondatachannel(sid, info)
>     fire_ondata(sid, buffered_data)
>   } else if (has_known_stream(sid)) {
>     fire_ondata(sid, data)
>   } else if (buffer_has_space(sid)) {
>     add_to_buffer(sid, data)
>   } else {
>     var buffered_data = clear_buffer(sid)
>     fire_unknownchannelerror_in_js(sid, buffered_data)
>     reset_stream(sid)
>   }
> }
> 
> 
> Are there other options I'm missing or didn't understand?
> 
> 
> 
> On Fri, Apr 19, 2013 at 11:11 AM, Martin Thomson <[e-mail]> wrote:
> On 19 April 2013 09:39, Randell Jesup <[e-mail]> wrote:
> > the Open *will* eventually get through unless you have
> > 100% (or virtually so) packet loss
> 
> I'm going to pretend you didn't say that.  If you want to talk odds,
> that's fine, but I think that you'll find that this sort of error is
> far more likely than you realize.  We're talking the probability of
> incoming data exceeding a given threshold prior to an open being
> delivered.  After all, unless you have 0% loss, the *possible* maximum
> amount of data is infinite.  Though large numbers might be of
> relatively low probability on an individual basis, operating at scale
> you are going to encounter surprising spikes.
> 
> > I honestly feel it's ok to just buffer all incoming packets while waiting for the Open.
> 
> That's not a warm fuzzy that I share.
> 
> > No one is going to get a gigabyte of data in without an Open...  A
> > non-browser could fake up a session and start sending data without ever
> > sending an Open... but flushing the data doesn't actually help you against
> > that sort of active DOS (they can just start again, they can spread it
> > across thousands of channels, etc, etc), and there are FAR better DOS
> > methods - all this would do is burn some CPU and some memory.
> 
> I think that would be a mistake.  This isn't about denial of service,
> it's about genuine usage cases that encounter errors.  The receiver
> can't use the receive window to apply back pressure if they are
> reading from the stream to look for the open message, so you end up
> with an unbounded amount of data.  The amount of data will scale with
> bandwidth delay product.  A long, fat pipe might burn more CPU and
> memory than you are willing to tolerate.
> 
> Then it comes down to what experience you want to provide to the
> unfortunates who encounter this problem.
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb