retransmission
Click on the red underlined text to get to the source
... TCP or SCTP sender can generally determine when a
retransmission was sent in error. This document presents two methods
for using duplicate notifications ...
... method is a
conservative algorithm to disambiguate unnecessary retransmissions
from loss events for the purpose of undoing unnecessary congestion
control changes.
...
... This document is intended to outline reasonable and safe algorithms
for detecting spurious retransmissions and discuss some of the
considerations involved. It is not intended to describe the only
possible method ...
... what a TCP or SCTP sender may do after a spurious retransmission is
detected. A number of proposals have been developed (e.g.,
[RFC3522 ...
...
When the purpose of detecting spurious retransmissions is to "undo"
unnecessary changes made to the congestion control state ...
... data sender ideally needs to determine:
(a) That spurious retransmissions in a particular window of data do
not mask real segment loss (congestion ...
... RFC3517]). The
following steps require an extension of such a 'scoreboard' to
incorporate a slightly longer history of retransmissions than called
for in [RFC3517]. The following steps MUST be taken upon the receipt
...
... DSACK reports may be indicating network duplication rather
than unnecessary retransmission. Note that some techniques
to further disambiguate network duplication from
...
... to further disambiguate network duplication from
unnecessary retransmission (e.g., the TCP timestamp option
...
... segments or chunks marked as retransmitted have also
been marked as acknowledged and duplicated, we conclude
that all retransmissions in the previous window of data
were spurious and no loss occurred.
...
... segment or chunk is still marked as retransmitted
but not marked as duplicate, there are outstanding
retransmissions that could indicate loss within this window
of data. We can make no conclusions based on this
particular DSACK ...
... RFC1323] to determine whether the ACK for a given retransmit is for
the original transmission or a retransmission. More generally,
[LK00] outlines the benefits of detecting spurious retransmits and
...
... SK03] slightly alters TCP's sending pattern
immediately following a retransmission timeout and then observes the
pattern of the returning ACKs. This pattern can indicate whether the
...
... RTO only works for spurious retransmits triggered by the
transport's retransmission timer.
Finally, [AP99 ...
... AP99] briefly investigates using the time between
retransmitting a segment via the retransmission timeout and the
arrival of the next ACK as an indicator of whether the retransmit was
...
... When f=1/2 the algorithm identifies roughly 59% of the needless
retransmission timeouts and identifies needed retransmits only 2.5%
of the time. As with F-RTO, this scheme only detects spurious
...
... RTO, this scheme only detects spurious
retransmits sent by the transport's retransmission timer.
...
... It is possible for the receiver to falsely indicate spurious
retransmissions in the case of actual loss, potentially causing a TCP
or SCTP sender ...
... out of
order by more than some threshold amount as a duplicate, assuming
that it is a retransmission. A sender using the above algorithm will
...
... sender using the above algorithm will
assume that the retransmission was spurious.
The ECN nonce ...
... Eifel Algorithm: Making TCP Robust Against Spurious Retransmissions. ACM Computer Communication Review, 30(1), January 2000. ...
... Sarolahti, P. and M. Kojo, "F-RTO: An Algorithm for Detecting Spurious Retransmission Timeouts with TCP and SCTP", Work in Progress ...