A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCP
draft-allman-tcp-sack-13

2003-03-06 - sent the RFC Ed note
RFC Editor

plese replace the following paragraph in section 2:
    For the purposes of this specification we define a ``duplicate
    acknowledgment'' as an acknowledgment (ACK) whose cumulative ACK
    number is equal to the current value of HighACK, as described in
    [RFC2581].

with
    For the purposes of this specification we define a ``duplicate
    acknowledgment'' as a segment that arrives with no data and an
    acknowledgment (ACK) number that is equal to the current value
    of HighACK, as described in [RFC2581].

2003-02-06 - from mark

I think this is a good catch.  There is a general lack of definition
for what constitutes a dupack.  But, I think that is an RFC2581.bis
haggle.  I think imposing the rule you sketch above is about right.
I might suggest the following text:

    For the purposes of this specification we define a ``duplicate
    acknowledgment'' as a segment that arrives with no data and an
    acknowledgment (ACK) number that is equal to the current value
    of HighACK, as described in [RFC2581].

2003-03-06 - discuss from Erik
    For the purposes of this specification we define a ``duplicate
    acknowledgment'' as an acknowledgment (ACK) whose cumulative ACK
    number is equal to the current value of HighACK, as described in
    [RFC2581].

If somebody reads this spec without having the background of
the previous congestion control literature they might take the
above to literally and assume that all segments with ACK=HighACK
are dups, when in fact this includes data segments sent in the reverse
direction. Thus ACK=HighACK and the SEQ=RNXT (and perhaps other conditions?)
is what defines a duplicate ack.

Could be fixed with rfc-editor note once we have the text.