W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

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

From: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
Date: Sat, 5 Mar 2016 12:10:33 -0800
Message-ID: <CAO249yewG_PeKNz5vLJtqQqL0PtHvZCoG6OhM=bumEPtbjvGiA@mail.gmail.com>
To: Willy Tarreau <w@1wt.eu>
Cc: Yoshifumi Nishida <nishida@sfc.wide.ad.jp>, Joe Touch <touch@isi.edu>, ietf-http-wg@w3.org
Hi Willy,

On Sat, Mar 5, 2016 at 10:07 AM, Willy Tarreau <w@1wt.eu> 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 <w@1wt.eu> 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
Received on Saturday, 5 March 2016 20:11:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC