Date: Wed, 17 Jul 2002 22:27:17 -0500 (CDT) From: Mike Silbersack <silby@silby.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: cvs-committers@FreeBSD.ORG, <cvs-all@FreeBSD.ORG> Subject: Re: cvs commit: src/sys/netinet tcp_timer.h Message-ID: <20020717220320.F83856-100000@patrocles.silby.com> In-Reply-To: <200207180233.g6I2X187004855@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 17 Jul 2002, Matthew Dillon wrote: > Mike, I think you are a bit confused. This is simply the MINIMUM > retransmit timeout. It is not the retransmit timeout that the TCP > stack will use. > > The TCP stack calculates the retransmission timeout (RTO) based on the > smoothed round trip time for a packet. It is highly unlikely that > retransmit timeouts will ever get as low as 3 ticks with HZ set to 1000, > but if they do it will be because the protocol demands it. > > We are already very conservative in our RTO calculations. I know, > because I revamped that whole section of code a few years ago. Yes, I understand that we're talking about the minimum. What I was misunderstanding was the point of "3". I initially thought that you were trying to set the floor to 30ms. I now see that you're trying to totally remove the floor, but that there's roundoff error / etc in the RTO calculation that you're trying to avoid. > I am not saying that having an absolute time minimum is unreasonable, > I am simply saying that 1 SECOND *IS* unreasonable. > > I would say that 200ms is also unreasonable. I would say that something > on the order of 50ms would be reasonable, but even 50ms can create > serious issues for something like, say, NAS networks. > > For this reason I really think we should trust the RTO calculation. > > -Matt > Matthew Dillon > <dillon@backplane.com> The RTO is not what is _causing_ problems: the packet loss which requires the use of a RTO is what causes the problem. You're not going to solve such packet loss by blasting out retransmissions ASAP, and such a drastic change will affect other situations (such as a short cable/hub/router outage) in profound ways. Tweaking the 1 second timeout down to 200ms is relatively simple. Allowing the RTO to go all the way down to 3*rtt is much more drastic, and could have many unexpected sideeffects that will be hard to track down. Mike "Silby" Silbersack 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?20020717220320.F83856-100000>