Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

There is still the need to define "a while".    IMHO, for "reliable" transport of the OPEN that could survive a routing transient, we are talking about roughly 30 seconds or 5 re-transmissions.   If we assume that only the OPEN is lost (no losses in the data),  required buffer = Timeout * min(RWIN, CWIN)/RTT .  This may not be small number. 
Example: Timeout = 30 seconds, min (CWIN, RWIN) = 16 KB, RTT = 50 ms,  buffer = 30 second * 16 KB/50 ms = 9.6 MB

From: pthatcher@google.com
Date: Tue, 23 Apr 2013 11:17:23 -0700
To: martin.thomson@gmail.com
CC: randell-ietf@jesup.org; rtcweb@ietf.org
Subject: Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

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.

On Fri, Apr 19, 2013 at 12:12 PM, Peter Thatcher <pthatcher@google.com> 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 <martin.thomson@gmail.com> wrote:

On 19 April 2013 09:39, Randell Jesup <randell-ietf@jesup.org> 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

rtcweb@ietf.org

https://www.ietf.org/mailman/listinfo/rtcweb

_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb 		 	   		  