[Tsvwg] resolving the problem of unnecessary fast retransmits in go-back-N

In go-back-N recovery TCP DUPACKs can result either from unnecessarily 
retransmitted packets
or from a loss of a retransmitted packet. [Flo94] from RFC2892 shows 
that this ambiguity can cause
unnecessary fast retransmits. A solution called "bugfix" in [F98] 
disables fast retransmits until go-back-N
recovery is completed. However, because the ambiguity is not resolved, 
"bugfix" causes timeouts and very long recovery if packets get lost 
during go-back-N.

The long-term solution to this problem is SACK (to prevent unnecessary 
retransmissions) and DSACK (to
resolve the DUPACK ambiguity if unnecessary retransmissions do happen). 
However, most TCP connections today still do not use SACK. 
http://www.icir.org/floyd/sack-questions.html

Until SACK is universally deployed two methods to resolve the DUPACK 
ambiguity might be useful.

ACK-heuristic: if seq(ack_new)-seq(ack_prev)<=2 MSS then trigger fast 
retransmit on 3rd DUPACK
This method is based on observation that to trigger a false fast 
retransmit, a TCP sender has to retransmit
unnecessarily at least 3 adjucent packets. In this case there will be a 
jump in a cumulative ACK at the sender of at least three segments.

Using the timestamp option: if ts_echo(ack_new) == ts (seg_una) then 
trigger fast retransmit on 3rd DUPACK
In case of a missing segment both RFC1323 or RFC1323bis (expired update 
draft) require that DUPACKs
echo a timestamp from the segment below the missing one.

Some algorithm to detect spurious timeouts should be used before 
applying these tests. I'm currently running experiments in ns2 to 
identify any possible corner cases. For example, if ACKs get lost, a 
lost data segment would not be detected by the ACK-heuristic.  However, 
if proposals work at least in common cases, using them is an improvement 
upon the "bugfix". Later I'll send a pointer to simulation results.

Andrei

_______________________________________________
tsvwg mailing list
tsvwg@ietf.org
https://www1.ietf.org/mailman/listinfo/tsvwg