Subject: [tcpm] RFC 2581 question

From: David Borman <[email-masked]>
Date: Fri, 20 Jan 2006 16:33:41 -0600

Hi,

I have a question about when to clear the duplicate ack counter.  RFC  
2581 says:

    The TCP sender SHOULD use the "fast retransmit" algorithm to detect
    and repair loss, based on incoming duplicate ACKs.  The fast
    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.  After receiving 3
    duplicate ACKs, TCP performs a retransmission of what appears to be
    the missing segment, without waiting for the retransmission timer to
    expire.

I'm questioning the description as 3 duplicate ACKs as "4 identical  
ACKs without the arrival of any other intervening packets".  Let's  
take a normal fast retransmit case:

	dupack == 0
	[101,200] ACK(1) ---->
					<---- ACK(200)
	[201,300] ACK(1) ----> LOST
	[301,400] ACK(1) ---->
					<---- ACK(200)
	dupack == 1
	[401,500] ACK(1) ---->
					<---- ACK(200)
	dupack == 2
	[501,600] ACK(1) ---->
					<---- ACK(200)
	dupack == 3 => Fast Retransmit!
	[101,200] ACK(1) ---->
					<---- ACK(600)

Now, let's say the other side decided to send 10 bytes of data in the  
middle:

	dupack == 0
	[101,200] ACK(1) ---->
					<---- ACK(200)
	[201,300] ACK(1) ----> LOST
	[301,400] ACK(1) ---->
					<---- ACK(200)
	dupack == 1
	[401,500] ACK(1) ---->
					<---- ACK(200)
	dupack == 2
					User writes 10 bytes of data
					<---- [1,10] ACK(200)
	Got an intervening packet, so reset:
	dupack = 0
	ACK(10) ------------->
	[501,600] ACK(10) ---->
					<---- ACK(200)
	dupack == 1
	No Fast Retransmit!!!

It seems to me that the dupack counter should only be cleared when an  
ACK for new data is received, whether it is in a pure ACK or  
piggybacked on a data packet.  Just the receipt of something other  
than a dup ack shouldn't cause the duplicate ack count to get reset.

Am I missing something?

			-David Borman

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Janardhan Iyengar <[email-masked]>
Date: Sat, 21 Jan 2006 14:04:33 -0500 (EST)

David,

> It seems to me that the dupack counter should only be cleared when an ACK for 
> new data is received, whether it is in a pure ACK or piggybacked on a data 
> packet.  Just the receipt of something other than a dup ack shouldn't cause 
> the duplicate ack count to get reset.

I took a quick look at the FreeBSD code, and I think you are right 
(someone correct me if this is not the case). I am also wondering what the 
reason for the clause "without any intervening packets" is.  I also do not 
see how your solution will work without SACK---how can a non-SACK sender 
determine when new data is being acked?

A sender could still "not do anything to the dupack count" when a 
piggybacked ack is received. In other words, the dupack count is changed 
on only pure acks and new acks. That is a fair estimate in this particular 
case, IMHO, that new data is being acked.

Anyone?

- jana

--------------------
Janardhan R. Iyengar 
http://www.cis.udel.edu/~iyengar
Protocol Engineering Lab, University of Delaware

---

From: Ethan Blanton <[email-masked]>
Date: Mon, 23 Jan 2006 21:51:28 -0500

Wow, I replied to an ancient email intending to reply to this one.
Just goes to show this question is common.  ;-)

>    the missing segment, without waiting for the retransmission timer to

You are correct that this discription is ambiguous at best, and
incorrect at worst.  There is a forthcoming revision of RFC2581 which
(hopefully) clarifies this issue.  We look forward to comments on the
draft...

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm