Re: Fwd: Re: [tcpm] FW: Call for Adoption: TCP Tuning for HTTP

[Willy Tarreau <[e-mail]>]

On Sat, Mar 05, 2016 at 05:27:34AM -0800, Yoshifumi Nishida wrote:
> Hi Willy,
> 
> On Thu, Mar 3, 2016 at 1:11 PM, Willy Tarreau <[e-mail]> wrote:
> 
> >
> >
> > Let me restate it :
> >   - the client cannot bypass the TW state because it has no way to know
> >     whether or not the server has closed after seeing the last ACK or
> >     is still waiting for it.
> >
> >   - the server when it sees a SYN with an ISN larger than the end of the
> >     previous window, *knows* that the client has closed, otherwise the
> >     client would be in LAST_ACK and couldn't send a SYN in this state.
> >     This is why servers recycle connections, and only in this case.
> >
> 
> Hmm, If there are multiple clients behind a NAT, the server cannot know if
> it´s coming from the same one or difference one.
> Also each client uses its own ISN (also timestamp). So, in this case, it is
> possible that the server will see a SYN from different client with an ISN
> smaller than the previous window or staled timestamp.

Yes except that as long as the load is not too high, the firewall will
pick a different port. And if the load is high enough to make the firewall
reuse existing ports, then the TW issue on the client side (here the
firewall being the client) persists.

> In this case, I guess server will send back old FIN ACK or reset, which
> causes the termination of the connection anyway.

Yes.

> If clients go into TIME_STATE, I think we can avoid this.

That's why I said in this thread that tuning is a matter of tradeoffs
depending on the side you're looking at. Server people often want to
move the burden to the client to have an infinite scale, client people
prefer to move the burden to the server to enable even smaller clients
to work, and intermediaries people have to compose with the best of both
worlds since they're both clients and servers, and see aggregated traffic
that often reaches protocol limits much earlier.

Regards,
Willy