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

[Yoshifumi Nishida <[e-mail]>]

Hi Willy,

On Sat, Mar 5, 2016 at 10:07 AM, Willy Tarreau <[e-mail]> wrote:

> 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愀 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.
>

Got it. Thanks for the clarification and that's basically what I felt when
I read the draft.
I would like to support the adoption of the draft, but at the same time, I
might want to see pros and cons for the techniques in the draft.
Then, I think it can be much more beneficial than some random info on
google search results.

Thanks,
--
Yoshi