From owner-freebsd-net@freebsd.org Fri Apr 15 17:05:20 2016 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3F30AED860 for ; Fri, 15 Apr 2016 17:05:20 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: from reviews.nyi.freebsd.org (reviews.nyi.freebsd.org [IPv6:2610:1c1:1:607c::16:b]) by mx1.freebsd.org (Postfix) with ESMTP id 7F59B1CF2 for ; Fri, 15 Apr 2016 17:05:20 +0000 (UTC) (envelope-from daemon-user@freebsd.org) Received: by reviews.nyi.freebsd.org (Postfix, from userid 1346) id E9A74C7DD; Fri, 15 Apr 2016 17:05:19 +0000 (UTC) Date: Fri, 15 Apr 2016 17:05:19 +0000 To: freebsd-net@freebsd.org From: "hiren (hiren panchasara)" Reply-to: D5872+325+9dea0574509cdbb3@reviews.freebsd.org Subject: [Differential] [Updated] D5872: tcp: Don't prematurely drop receiving-only connections Message-ID: <83a03c2539e897161fee4a3e4274beaa@localhost.localdomain> X-Priority: 3 X-Phabricator-Sent-This-Message: Yes X-Mail-Transport-Agent: MetaMTA X-Auto-Response-Suppress: All X-Phabricator-Mail-Tags: , Thread-Topic: D5872: tcp: Don't prematurely drop receiving-only connections X-Herald-Rules: <64> X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-To: X-Phabricator-Cc: Precedence: bulk In-Reply-To: References: Thread-Index: MmVmNzYzNzljOGQxMmM4MWI4MmNjYzcxMzczIFcRH08= MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="utf-8" X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.21 List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2016 17:05:20 -0000 hiren added a comment. In https://reviews.freebsd.org/D5872#127123, @jtl wrote: > > The key feature that makes the retransmit timer inappropriate for an ACK-only case is that it is only stopped when we receive input; however, in the ACK-only case, we really want to stop it as soon as we transmit a successful ACK. Indeed. I guess we want to treat internal insufficient memory error with retransmit timer remedy. One would also argue that do you really want to go on when you failed to respond (with the ACK) for these many times. Don't you have bigger problems by now? > Of course, we could just drop the ACK and everything would "just work". But, it //probably// is still a good idea to try to re-transmit the ACK. I am not opposed to the suggested patch but its just...weird. (Also if its not obvious, I don't have a better solution to present. :-)) REVISION DETAIL https://reviews.freebsd.org/D5872 EMAIL PREFERENCES https://reviews.freebsd.org/settings/panel/emailpreferences/ To: sepherosa_gmail.com, network, glebius, lstewart, adrian, delphij, decui_microsoft.com, honzhan_microsoft.com, howard0su_gmail.com, freebsd-net-list, transport, jtl, hiren Cc: jtl