segment
Click on the red underlined text to get to the source
... RFC2960] provide notification of duplicate
segment receipt through duplicate selective acknowledgment (DSACK)
...
... notifications
will suffice. For instance, if a stack simply wants to know (for
some reason) the number of spuriously retransmitted segments,
counting all duplicate notifications for retransmitted segments ...
... segments,
counting all duplicate notifications for retransmitted segments
should work well. Another application of this strategy is to monitor
and adapt transport ...
... algorithm to determine whether fast
retransmitting [RFC2581] segments with a lower than normal duplicate
ACK threshold ...
... (a) That spurious retransmissions in a particular window of data do
not mask real segment loss (congestion).
...
... congestion).
For example, assume segments N and N+1 are retransmitted even
though only segment N was dropped by the network ...
... For example, assume segments N and N+1 are retransmitted even
though only segment N was dropped by the network (thus, segment
...
... though only segment N was dropped by the network (thus, segment
N+1 was needlessly retransmitted). When the sender receives the
...
... sender receives the
notification that segment N+1 arrived more than once it can
conclude that segment N+1 was needlessly resent. However, it
...
... notification that segment N+1 arrived more than once it can
conclude that segment N+1 was needlessly resent. However, it
cannot conclude that it is appropriate to revert the congestion
control state ...
... (by receiving a duplication notification for a segment that was
not retransmitted by the sender).
...
... sending rate is the conservative approach.
(A.2) If the segment was retransmitted exactly one time, mark it
as a duplicate.
...
... as a duplicate.
(A.3) If the segment was retransmitted more than once processing
of this DSACK MUST be terminated and the congestion control ...
... current window of data.
(A.4) If the segment was not retransmitted the incoming DSACK
indicates that the network ...
... DSACK
indicates that the network duplicated the segment in
question. Processing of this DSACK MUST be terminated. In
...
... allow for the continued use of the algorithm in the face of
duplicated segments. We do not delve into such an
algorithm in this document due the current rarity of
...
...
(B) Assuming processing is allowed to continue (per the (A) rules),
check all retransmitted segments in the previous window of data.
(B.1) If all segments ...
... segments in the previous window of data.
(B.1) If all segments or chunks marked as retransmitted have also
been marked as acknowledged and duplicated, we conclude
that all retransmissions ...
... were spurious and no loss occurred.
(B.2) If any segment or chunk is still marked as retransmitted
but not marked as duplicate, there are outstanding
retransmissions ...
... pattern of the returning ACKs. This pattern can indicate whether the
retransmitted segment was needed. The advantage of F-RTO is that the
algorithm ...
... Finally, [AP99] briefly investigates using the time between
retransmitting a segment via the retransmission timeout and the
arrival of the next ACK ...
...
Consider the following scenario: A receiver watches every segment or
chunk that arrives and acknowledges any segment that arrives out of
order ...
... receiver watches every segment or
chunk that arrives and acknowledges any segment that arrives out of
order by more than some threshold amount as a duplicate, assuming
...
... receiver will not know the ECN nonce from the original
segment and therefore will probabilistically not be able to fool the
sender for long. [RFC3540 ...
... Blanton, E., Dimond, R. and M. Allman, "Practices for TCP Senders in the Face of Segment Reordering", Work in Progress, February 2003. ...