Re: [rtcweb] #13: Transport of DATA_CHANNEL_OPEN

On Apr 19, 2013, at 8:11 PM, Martin Thomson 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.
If you are thinking about a sender violating the spec, then you are right.
If the sender is following the spec, then SCTP will get the OPEN_REQ through.
The amount of data is limited by the send buffer size, since all data sent
after the OPEN_REQ is only SACKed and needs to be buffered (unless you use
NR_SACKs).

Best regards
Michael
> 
> 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
> 