From owner-cvs-all Wed Jul 17 18: 2:16 2002 Delivered-To: cvs-all@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 355E237B400; Wed, 17 Jul 2002 18:02:10 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC50743E6A; Wed, 17 Jul 2002 18:02:09 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.5/8.12.4) with ESMTP id g6I129CV004351; Wed, 17 Jul 2002 18:02:09 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.5/8.12.4/Submit) id g6I129Gw004350; Wed, 17 Jul 2002 18:02:09 -0700 (PDT) (envelope-from dillon) Date: Wed, 17 Jul 2002 18:02:09 -0700 (PDT) From: Matthew Dillon Message-Id: <200207180102.g6I129Gw004350@apollo.backplane.com> To: Mike Silbersack Cc: cvs-committers@FreeBSD.ORG, Subject: Re: cvs commit: src/sys/netinet tcp_timer.h References: <20020717185653.C82638-100000@patrocles.silby.com> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :1 second is an accepted minimum for retransmit timeouts. Please back this :out, and go find out why fast retransmits aren't handling minor packet :loss. : :Mike "Silby" Silbersack Either we trust the RTT's we calculate or we don't. If we trust the RTTs we calculate then the one second minimum is absurd. Actually, I think the one second minimum is absurd anyway, so no, I am not going to back it out. The minimum is calculated from the RTT and this calculation is already very conservative. I have two people.. and I can reproduce this myself as well, getting one second glitches in downloads on networks with minor packet loss, one over a 1MBit radio network and one over a gigabit ethernet, with or without newreno turned on. I have been and I am still attempting to track down a number of issues with our TCP stack, but insofar as the fast retransmit goes the basic problem is not with the fast retransmission... that actually works. The problem is with restarting the packet stream AFTER the fast retransmission. There appear to be a number of situations where the restart, even with a single packet loss, DOES NOT WORK, and the entire stream balks for 1 whole second when it shouldn't. From where I sit it looks like the ack returned after the restart packet is being ignored (that is, not causing another packet to be sent). As far as I can tell the ack is being properly ignored because we do not appear to be tracking the restart sequence number at all and the ack from the fast retransmit is obviously not going to be an ack for everything up to the max sequence number we sent. If we are, point it out. I can't find it. It's trivial to reproduce, just use dummynet and set the packet loss to 1% and BEWM. You are welcome to go look for the problem yourself, I haven't had any luck. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message