Open main menu
Home
Random
Recent changes
Special pages
Community portal
Preferences
About Wikipedia
Disclaimers
Incubator escapee wiki
Search
User menu
Talk
Dark mode
Contributions
Create account
Log in
Editing
Transmission Control Protocol
(section)
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
=====Timeout-based retransmission===== When a sender transmits a segment, it initializes a timer with a conservative estimate of the arrival time of the acknowledgment. The segment is retransmitted if the timer expires, with a new timeout threshold of twice the previous value, resulting in [[exponential backoff]] behavior. Typically, the initial timer value is {{math|smoothed RTT + max(''G'', 4{{times}}RTT variation)}}, where {{mvar|G}} is the clock granularity.{{sfn|RFC 6298|p=2}} This guards against excessive transmission traffic due to faulty or malicious actors, such as [[man-in-the-middle attack|man-in-the-middle]] [[denial of service attack]]ers. Accurate RTT estimates are important for loss recovery, as it allows a sender to assume an unacknowledged packet to be lost after sufficient time elapses (i.e., determining the RTO time).{{sfn|Zhang|1986|p=399}} Retransmission ambiguity can lead a sender's estimate of RTT to be imprecise.{{sfn|Zhang|1986|p=399}} In an environment with variable RTTs, spurious timeouts can occur:{{sfn|Karn|Partridge|1991|p=365}} if the RTT is under-estimated, then the RTO fires and triggers a needless retransmit and slow-start. After a spurious retransmission, when the acknowledgments for the original transmissions arrive, the sender may believe them to be acknowledging the retransmission and conclude, incorrectly, that segments sent between the original transmission and retransmission have been lost, causing further needless retransmissions to the extent that the link truly becomes congested;{{sfn|Ludwig|Katz|2000|p=31-33}}{{sfn|Gurtov|Ludwig|2003|p=2}} selective acknowledgement can reduce this effect.{{sfn|Gurtov|Floyd|2004|p=1}} {{harvtxt|RFC 6298}} specifies that implementations must not use retransmitted segments when estimating RTT.{{sfn|RFC 6298|p=4}} [[Karn's algorithm]] ensures that a good RTT estimate will be produced—eventually—by waiting until there is an unambiguous acknowledgment before adjusting the RTO.{{sfn|Karn|Partridge|1991|p=370-372}} After spurious retransmissions, however, it may take significant time before such an unambiguous acknowledgment arrives, degrading performance in the interim.{{sfn|Allman|Paxson|1999|p=268}} TCP timestamps also resolve the retransmission ambiguity problem in setting the RTO,{{sfn|RFC 6298|p=4}} though they do not necessarily improve the RTT estimate.{{sfn|RFC 7323|p=7}}
Edit summary
(Briefly describe your changes)
By publishing changes, you agree to the
Terms of Use
, and you irrevocably agree to release your contribution under the
CC BY-SA 4.0 License
and the
GFDL
. You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license.
Cancel
Editing help
(opens in new window)