Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Michael Tuexen <[e-mail]>]

On Apr 24, 2013, at 5:25 AM, Bernard Aboba wrote:

> 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
I guess you are considering the case where the OPEN message was dropped by the network multiple times...

The sender and receiver normally bound the memory for processing data (socket buffers). So
your above only applies if the send buffer is larger than 9.6 MB. Ofter, the send and
receiver buffer are the same and reflect the RWIN, so you are considering on the receiver
side a 16 KB buffer, on the sender side a 10 MB buffer.

The sender can not delete message sent after the OPEN message, since they can be reneged at the
SCTP layer.

Best regards
Michael
> 
> 
> From: [e-mail]
> Date: Tue, 23 Apr 2013 11:17:23 -0700
> To: [e-mail]
> CC: [e-mail]; [e-mail]
> 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 <[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]://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb