Subject: RE: [tcpm] RFC 2581 question

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 23 Jan 2006 16:17:34 -0800

I seem to recall that, in the course of revising NewReno, we raised some
discussion with Mark about the ambiguity of what constitutes a dupack
(in our discussion at the time, we were noticing that pure window
updates were inappropriately resetting the NewReno dupack counter), and
I believe that he mentioned it as one of the issues to be taken up in
2581bis.

Tom

> -----Original Message-----
> From: Janardhan Iyengar [mailto:[email-masked]] 
> Sent: Saturday, January 21, 2006 11:05 AM
> To: David Borman
> Cc: [email-masked]
> Subject: Re: [tcpm] RFC 2581 question
> 
> 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
> 
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/tcpm
> 

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

---

From: "Krejsa, Dan" <[email-masked]>
Date: Wed, 25 Jan 2006 19:00:19 -0800

Ethan Blanton Wrote:
> 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?

  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?

Yup, I think it does!

- Dan