Re: Feedback on TCP Fast Open?

Hi Willy

On Fri, Aug 2, 2013 at 10:34 PM, Willy Tarreau <w@1wt.eu> wrote:
> Hi Amos,
>
> On Sat, Aug 03, 2013 at 12:05:15PM +1200, Amos Jeffries wrote:
>> On 3/08/2013 11:19 a.m., Peter Lepeska wrote:
>> >"it's unclear how beneficial it would
>> >> be for us since we already have such gains for browser preconnect (our
>> >> browser feature that learns from past web browsing to speculatively
>> >> establish connections, typically just TCP connections but perhaps doing a
>> >> TLS or other handshakes too as needed)"
>> >
>> >It would benefit any time you encounter a host that preconnect has not
>> >learned about yet. Surely this provides a benefit.
>>
>> Yet assuming TFO does require that prior key exchange mentioned by Nico
>> (I have not yet read the TFO spec). That means that preconnect will has
>> also already been done right?
>> So gains are 0 in that case.
>
> Not exactly, just that an earlier connection would have already been made
> to the same site, so exactly as for preconnect as William described it
> (since the browser decides to connect based on browsing history). So from
> this point it is similar.
>
>> Its main benefit seems to be allowing for prefetching to be skipped or
>> short-circuited if it is used as the initial step of such prefetch.
>
> The benefit I'm seeing mainly is not to maintain idle connections to
> servers which do not know if they can kill them or not. However we don't
> know if the TFO SYN will pass, which is a real issue (hence my proposal to
> use TFO in preconnect and to send a harmless request such as GET favicon).
>
>> >It also has lower cost since it will result in fewer (zero) connection
>> >mistakes since it's not doing anything speculatively. Don't get me
>> >wrong I'm a big fan of the benefits of speculative prefetching in
>> >general, but only in the case where the underlying protocol can't
>> >solve the problem without mistakes.
>> >
>> >TCP Fast Open seems great as long as it doesn't introduce any other
>> >problems (such as increased DoS vulnerability).
>>
>> It is clearly lowering the capacity barrier SYN-flood DDoS need to reach
>> in exchange for 1 RTT on legitimate TCP setup.
>> The big question though is; overall which are more common: DDoS
>> SYN-flood packets or legitimate SYN?
>
> It depends. I've been involved in dealing with multi-10G SYN flood attacks
> on some large infrastructures which surprizingly did not get that many
> connections normally. So if we do the math, 30-40 Mpps for 4 hours is
> about 500 billion SYN, which is about 200k SYN/s over one month. So such
> an attack for 4 hours every month produces 10 times more SYNs than clients
> running at 20k conn/s. But what matters really is the user experience.
>
> That said, I'm not that much afraid of SYN floods with TFO at the moment,
> for multiple reasons :
>   - attackers still don't send TFO and will probably not do for a long
>     time since it reduces the reach probability
>   - normal SYN floods are already enough
>   - one of the benefits of TFO is that you don't have to respond to validate
>     the packet. So you have everything in it to decide whether it's valid or
>     not. OK it takes CPU time, but not much more than building a SYN cookie
>     and sending it back.
>
> I also remember when experimenting with TFO on Linux that sometimes it stopped
> accepting it when I was flooding it, I suspect that if the failure rate is too
> high, it might decide to disable it, but I'm not sure about this since it was
> a very early implementation (so it might as well have been a bug).
Yes it's an intentional feature :) we design & impl. TFO with caution
about the middleboxes from day one.

If the SYN-data never gets acked, TFO socket retries with a pure,
normal SYN (w/o data or any option), and the connection falls back to
regular TCP.

(Linux-specific) If the handshake completes with that, we know this
path is not quite TFO friendly so the client remembers that. If this
recurs another time we disable TFO for a while and all connections to
that server use regular TCP.

>
> Best regards,
> Willy
>
>

Received on Friday, 9 August 2013 23:37:21 UTC