Date: Wed, 17 Jul 2002 21:16:53 -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: <200207180416.g6I4GrLM005311@apollo.backplane.com> References: <20020717220320.F83856-100000@patrocles.silby.com>
next in thread | previous in thread | raw e-mail | index | archive | help
: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.
I'm not sure what your point is here. Retransmit timeouts are only an
issue when packet loss is present. We can't just declare packet loss to
be bad and ignore it, after all. And I have to disagree with your
characterization of the retransmit as 'blasting it out ASAP'. That is
not what occurs. The RTO mechanism is fairly conservative.
: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
The whole point of the RTO calculation is to avoid the side effects.
If the side effects go beyond triviality then our RTO calculation is
not being done properly. It's that simple. Either our RTO calculation
is right or it is wrong.
-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?200207180416.g6I4GrLM005311>