Date: Wed, 17 Jul 2002 18:02:09 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Mike Silbersack <silby@silby.com> Cc: cvs-committers@FreeBSD.ORG, <cvs-all@FreeBSD.ORG> Subject: Re: cvs commit: src/sys/netinet tcp_timer.h Message-ID: <200207180102.g6I129Gw004350@apollo.backplane.com> References: <20020717185653.C82638-100000@patrocles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207180102.g6I129Gw004350>