Subject: Fast retransmit/recovery (RFC 2581) ...

From: Ramesh Shankar <[email-masked]>
Date: Sat, 01 Jul 2000 12:21:59 -0600

Okay, this time it is related to RFC 2581 ("Reno") style fast retransmit
recovery :-)).

Clearing of t_dupacks in FreeBSD/NetBSD:

Assume that we have started getting dup ACKs. We may or may not have
done a fast retransmit and we may or may not be in fast recovery.
t_dupacks is cleared in the following cases:

CASE 1: When a partial or a full ACK is received.
CASE 2: On a retransmit timeout.
CASE 3: Got a dup ACK [SEG.ACK == SND.UNA], but has a window update
[SEG.WND != SND.WND]. 
CASE 4: Dup ACK, but has data.
CASE 5: SEG.ACK < SND.UNA.

RFC 2581, page 6 says, "The retransmit algorithm uses the arrival of 3
duplicate ACKs (4 identical ACKs *without* the arrival of any other
intervening packets) as an indication that a segment has been lost".

Interpreting the RFC strictly, CASES 3, 4 and 5 seem okay. However, it
is not entirely clear why these cases have to reset t_dupacks. I can
understand if t_dupacks doesn't get bumped up by such segments, but why
clear it? Is there any specific reason for this or just plain paranoia?

The issue, however, is that this would cause grief during bidirectional
data transfer (here we go again!). Between the time the first dup ACK
comes in and a partial or full ACK is received, if CASE 3, 4, or 5 is
encountered, we reset t_dupacks. Interestingly, CWND doesn't get
deflated! There is a break statement which skips the CWND deflation in
CASES 3,4 and 5.

The second confusion is related to Peterson and Brakmo's fix to the
header prediction code to deflate the window. It is not clear to me what
happens when t_dupacks != 0, but t_dupacks < tcprexmtthresh. The header
prediction code handles such an ACK, but doesn't seem to set t_dupacks
to 0. Isn't possible that we may end up doing a false fast retransmit
sometime later? It is hard to see from the code whether this case is
correctly handled or not.

Any clarification would be greatly appreciated.

Thanks,

S.R.

---

From: Mark Allman <[email-masked]>
Date: Sat, 01 Jul 2000 23:57:29 -0400

> Interpreting the RFC strictly, CASES 3, 4 and 5 seem
> okay. However, it is not entirely clear why these cases have to
> reset t_dupacks. I can understand if t_dupacks doesn't get bumped
> up by such segments, but why clear it? Is there any specific
> reason for this or just plain paranoia?

The problem is the ACKs are ambiguous when deciding if they are
"duplicates" or not.  I.e., is this a pure window update or is it a
real duplicate ACK that also happens to update the window?  Does
this data segment that includes a delayed ACK really convey a
delayed ACK or was the data just sent before a new data segment was
received (i.e., the ACK number has to be duplicate)?  It would seem
to me that the conservative thing to do is to reset things and wait
for clear signals that something is lost.

(A side note: I would think SACK would help this situation a bit.
 For example, an ACK with a duplicate ACK number, data and no SACK
 information (in a SACK enabled flow) can easily be ignored as it is
 quite obviously just a data segment and does not signal the arrival
 of out-of-order data.)

allman

---
http://roland.grc.nasa.gov/~mallman/