netdev - Re: [PATCH net-next] tcp: do not increase the rcv window when the FIN has been received

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20140103.195810.465225289648295955.davem@davemloft.net>
Date:	Fri, 03 Jan 2014 19:58:10 -0500 (EST)
From:	David Miller <davem@...emloft.net>
To:	w@....eu
Cc:	eric.dumazet@...il.com, netdev@...r.kernel.org
Subject: Re: [PATCH net-next] tcp: do not increase the rcv window when the
 FIN has been received

From: Willy Tarreau <w@....eu>
Date: Thu, 2 Jan 2014 23:40:21 +0100

> In HTTP performance tests it appeared that my client was always sending
> an ACK immediately after receiving the FIN from the server and that the
> sole purpose of this ACK was to advertise a larger window.

I guess the question is what behavior do we want here.

Frankly, I think we should always immediately ACK a FIN _unless_ we
already have data pending on the send queue on which to piggyback that
ACK.

The reason is that since we know there will be no more data, delaying
the ACK has none of the useful characteristics.  In fact, sending the
ACK immediately will allow the closing side to release the data in it's
retransmit queue, and thus reclaim memory, more quickly.

I'm not so sure about this change, so I'm marking it deferred.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html