Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

[Martin Thomson <[e-mail]>]

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.