Subject: RE: [tcpm] RFC 2581 question

From: "Krejsa, Dan" <[email-masked]>
Date: Wed, 25 Jan 2006 18:31:27 -0800

Hi Ethan,

I like the duplicate ACK definition in the new draft, however
I'm not sure the draft addresses David's particular question
regarding the phrase 'without the arrival of any other intervening
packets'.  What is the reason for this restriction?  If
a segment arrives which is not a 'duplicate ACK' according
to the definition, but which does not acknowledge new data,
should the duplicate ACK count really be zeroed as this phrase
seems to imply?

- Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Ethan Blanton
Sent: Monday, January 23, 2006 6:51 PM
To: Borman, David
Cc: [email-masked]
Subject: Re: [tcpm] RFC 2581 question

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

David Borman spake unto us the following wisdom:
> 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.

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...

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

---

From: Ethan Blanton <[email-masked]>
Date: Wed, 25 Jan 2006 21:52:02 -0500

> should the duplicate ACK count really be zeroed as this phrase

Yes, this was brought up to us by another reader off-list ... I
thought this was cleaned up when the dupack definition was added, but
I have now seen that it was not.  I have proposed the following text
for the second paragraph of 3.2:

    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 (as
    defined in section 2, without any intervening ACKs which move
    SND.UNA) 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.

Does this look better to you?

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