From owner-freebsd-net@FreeBSD.ORG Fri Jul 13 17:54:50 2012 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AD5A81065670 for ; Fri, 13 Jul 2012 17:54:50 +0000 (UTC) (envelope-from reese@myri.com) Received: from myri.com (rrcs-24-43-81-194.west.biz.rr.com [24.43.81.194]) by mx1.freebsd.org (Postfix) with ESMTP id 8E9618FC0C for ; Fri, 13 Jul 2012 17:54:50 +0000 (UTC) Received: from ssl-tls.localdomain (ssl-tls.myri-local.com [172.31.0.162]) by myri.com (8.13.7+Sun/8.13.7) with ESMTP id q6DHsoaG028159 for ; Fri, 13 Jul 2012 10:54:50 -0700 (PDT) Received: from [172.31.195.150] (unknown [172.31.195.150]) by ssl-tls.localdomain (Postfix) with ESMTP id 34DEDD0D6CD for ; Fri, 13 Jul 2012 10:54:50 -0700 (PDT) Message-ID: <500060DB.3090407@myri.com> Date: Fri, 13 Jul 2012 10:54:35 -0700 From: Reese Faucette User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: freebsd-net@freebsd.org References: <4FFF9E48.6000403@myri.com> In-Reply-To: <4FFF9E48.6000403@myri.com> X-Forwarded-Message-Id: <4FFF9E48.6000403@myri.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: question in tcp_do_segment() X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jul 2012 17:54:50 -0000 Hi, freebsd-net- I don't have a testcase for this at the moment, but there's a test in tcp_do_segment that looks backwards to me... http://svnweb.freebsd.org/base/release/9.0.0/sys/netinet/tcp_input.c?view=markup line 2398 - if (!tcp_timer_active(tp, TT_REXMT) || th->th_ack != tp->snd_una) tp->t_dupacks = 0; says "If we get a DUP ack and the retransmit timer is NOT fired, then ignore it and reset DUP ACK count." Isn't that exactly backwards? I could see ignoring the DUP ACK if we know the retransmit timer HAS fired, and we don't want to interfere with its retransmission efforts. The way the code is written now, as far as I can see, completely defeats retransmission based on DUP acks. I accidentally ran across this by breaking the timer, so that the retransmit timer never fires, and my streams get stuck, even with plenty of DUP ACKs. Am I missing something, or should that "!" go ? Thanks, Reese Faucette Myricom, Inc.