[e2e] Some questions about TCP.

[Ethan Blanton]

Detlef Bosau spake unto us the following wisdom:
> 1.: What is the correct behaviour of a TCP receiver when it receives  
> data which is already acknowledged?

Send an ACK for the current cumulative ACK point.  Whether that is an
ACK piggybacked on an outgoing data segment or a pure ACK is
immaterial in this case.  See RFC 793:

    3.  If the connection is in a synchronized state (ESTABLISHED,
    FIN-WAIT-1, FIN-WAIT-2, CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT),
    any unacceptable segment (out of window sequence number or
    unacceptible acknowledgment number) must elicit only an empty
    acknowledgment segment containing the current send-sequence number
    and an acknowledgment indicating the next sequence number expected
    to be received, and the connection remains in the same state.

> The question arises in the context of SNOOP, because SNOOP introduces a  
> DUPACK filtering in cases where a packet is duplicated by the SNOOP  
> recovery mechanism.
>
> To my understanding, the correct behaviour would simply do nothing.

This is broken, and can prevent progress on the connection.  If the
sender of this out-of-window segment sent it because it has not
received a valid acknowledgement for the segment, then failing to
acknowledge it with the current cumulative ACK point will leave the
sender in loss recovery indefinitely.

[Snip question on RTO; I'm not going to take a position on this, as it
 seems valid to me to either leave the current timer running, or
 restart it on Fast Retransmit.  The decision in this case probably
 depends on how conservative your RTO is.  Certainly it is *not* valid
 to start a new RTO only on transmission of new, previously unsent
 data.]

> My questions may be a bit annoying, but from what I've seen in the last  
> weeks, particularly in quite some private mail off list, is that there  
> is quite some unspoken agreement here and that quite some information in  
> the RFC is given a bit between the lines.
>
> One of these is the _definite_ distinction between "piggyback acks",  
> which are _never_ DUPACKs and pure acks, which
> _can_ be DUPACKS, under certain conditions given in RFC 5681.

I feel like the definition of duplicate acknowledgment (for non-SACK
loss recovery) is pretty clear in 5681, and should clear up any
ambiguity which was present prior to this document.

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 481 bytes
Desc: Digital signature
Url : http://mailman.postel.org/pipermail/end2end-interest/attachments/20100119/cc5ca5af/attachment.bin