Re: [PATCH net-next 1/2] tcp: remove per-destination timestamp cache

On Thu, Mar 16, 2017 at 7:31 AM, Lutz Vieweg [off-list ref] wrote:

On 03/15/2017 11:55 PM, Willy Tarreau wrote:

quoted

At least I can say I've seen many people enable it without understanding its impact, confusing it
with tcp_tw_reuse, and copy-pasting it from random blogs and complaining about issues in
production.

I currently wonder: What it the correct advise to an operator who needs
to run one server instance that is meant to accept thousands of new,
short-lived TCP connections per minute?

Note that for this to be a problem there would have to be thousands of
new, short-lived TCP connections per minute from a single source IP
address to a single destination IP address. Normal client software
should not be doing this. AFAIK this is pretty rare, unless someone is
running a load test or has an overly-aggressive monitoring system. NAT
boxes or proxies with that kind of traffic should be running with
multiple public source IPs.

But if/when the problem occurs, then the feasible solutions I'm aware
of, in approximate descending order of preference, are:

(1) use longer connections from the client side (browsers and RPC libraries are
    usually pretty good about keeping connections open for a long time, so this
    is usually sufficient)

(2) have the client do the close(), so the client is the side to carry the
    TIME_WAIT state

(3) have the server use SO_LINGER with a timeout of 0, so that
    the connection is closed with a RST and the server carries no
    TIME_WAIT state

neal