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: Joe Touch <touch@isi.edu>
Date: Wed, 2 Mar 2016 15:34:42 -0800
To: Willy Tarreau <w@1wt.eu>
Cc: touch@isi.edu, ietf-http-wg@w3.org
Message-ID: <56D77892.2000308@isi.edu>


On 3/2/2016 3:21 PM, Willy Tarreau wrote:
> On Wed, Mar 02, 2016 at 02:34:38PM -0800, Joe Touch wrote:
>> - it has significant errors
>>
>> 	TIME-WAIT issues apply to servers, not clients.
> 
> Sorry but no it's the opposite. 

TIME-WAIT is a state caused by the side that closes the connection.

In the bulk of HTTP connections, the server closes the connection,
either to drop a persistent connection or to indicate "EOF" for a transfer.

Clients generally don't enter TIME-WAIT, so reducing the time they spend
in a state they don't enter has no effect.

> A server has no issue with knowing that
> a SYN belongs to a new session by seeing its ISN greater than the end
> of the previous window. 

That's exactly the reason the server keeps information in the TIME-WAIT
state.

> On the opposite, a client cannot know if the
> remote server it wants to connect to is safe for reuse 

TIME-WAIT isn't just for new connections; it's to protect against
injecting traffic from previous connections that is delayed into new
connections...

> and will refrain
> from establishing a new connection during the whole TIME_WAIT state,
> effectively preventing itself from doing its job.

If that's what it doesn, that's not TIME-WAIT - it's some new state in
the OS to avoid the possibility of hitting a TIME-WAIT at the server.
That's mislabeled at best, and defeats the entire purpose of the
TIME-WAIT at the server anyway.

Joe
Received on Wednesday, 2 March 2016 23:36:40 UTC

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