Please Whitelist This Site?
I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :)
If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads.
If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK.
Thanks for your understanding!
Sincerely, Charles Kozierok
Author and Publisher, The TCP/IP Guide
NOTE: Using software to mass-download the site degrades the server and is prohibited.
If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.
TCP Adaptive Retransmission and Retransmission Timer Calculations
(Page 1 of 3)
Whenever a TCP segment is transmitted,
a copy of it is also placed on the retransmission
queue. When the segment is placed on the
queue, a retransmission timer is started for the segment, which starts
from a particular value and counts down to zero. It is this timer that
controls how long a segment can remain unacknowledged before the sender
gives up, concludes that it is lost and sends it again.
The length of time we use for retransmission
timer is thus very important. If it is set too low, we might start retransmitting
a segment that was actually received, because we didn't wait long enough
for the acknowledgment of that segment to arrive. Conversely, if we
set the timer too long, we waste time waiting for an acknowledgment
that will never arrive, reducing overall performance.
Difficulties in Choosing the Duration of the Retransmission Timer
Ideally, we would like to set the
retransmission timer to a value just slightly larger than the round-trip
time (RTT) between the two TCP devices, that is, the typical time
it takes to send a segment from a client to a server and the server
to send an acknowledgment back to the client (or the other way around,
of course). The problem is that there is no such typical
round-trip time. There are two main reasons for this:
- Differences In Connection Distance: Suppose
you are at work in the United States, and during your lunch hour you
are transferring a large file between your workstation and a local server
connection using 100 Mbps Fast Ethernet, at the same time you are downloading
a picture of your nephew from your sister's personal Web sitewhich
is connected to the Internet using an analog modem to an ISP in a small
town near Lima, Peru. Would you want both of these TCP connections to
use the same retransmission timer value? I certainly hope not!
- Transient Delays and Variability: The
amount of time it takes to send data between any two devices will vary
over time due to various happenings on the internetwork: fluctuations
in traffic, router loads and so on. To see an example of this for yourself,
try typing ping www.tcpipguide.com from the command line
of an Internet-connected PC and you'll see how the reported times can
|If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support!|
Table Of Contents - Contact Us
The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005
© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.