[e2e] Some questions about TCP.

[Ethan Blanton]

Detlef Bosau spake unto us the following wisdom:
> Ethan Blanton wrote:
>> 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:
>
> Not quite, because only pure ACKs can be "DupAcks", refer to RFC 5681.

I'm quite familiar with RFC 5681.  ;-)

The point is, whether the ACK you send is a duplicate ACK or an ACK
piggybacked on a data segment, either way you will prevent the
*correctness* issue which could cause the connection to fail to make
progress.

> And the focus of my question is DupAck filtering (see Hari Balakrishnans  
> PhD thesis).

My answer is orthogonal to dupack filtering.  The point is, the
receiver must emit *some* sort of packet containing the current
cumulative ACK point to prevent dead/livelock (depending on how you
want to look at it) ending in abortive connection termination.

>>> 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
>>   
>
> Why? Perhaps, "doing nothing" is misleading.
>
> Of course, the receiver maintains its ACK counter and sends this 
> piggybacked with the next sent segment. However, it does not send a
> _pure_ ACK, hence does not see any "DupAcks".
>
> That's what I wanted to say.

If and only if the receiver has data available to send, and can send
it immediately or nearly immediately according to the various
congestion control rules in place, then it is perfectly fine from a
*correctness* point of view to stifle the duplicate ACK.  I believe
the standard calls for an immediate duplicate ACK, although, as
someone (Noel?  Bob?) previously pointed out, RFC 793 does not use the
term "duplicate ACK" in precisely this fashion.

>> 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.
>
> Really? First: Is a duplicate packet really an out of sequence packet?
> Out of window is not yet clear to me, because the receiver does not
> see the actual window. Second: When the sender did not receive an
> acknowledgement for this segment (it may be an erroneous
> retransmission due to a lost ACK) on time, it must retransmit the
> segment. As often as necessary.

Yes.  Read RFC 793.  A duplicate packet which falls below RCV.NXT is
out of sequence.  A duplicate packet falling between RCV.NXT and the
end of the receiver's window (RCV.NXT + RCV.WND) may be another issue;
it is, however, also my opinion that emitting an immediate dup ACK for
such a segment is the correct behavior.

The problem with your retransmission scenario, is that if the receiver
does not emit a segment with the correct cum ACK point in response to
segments falling below the current receive window, the sender could
continue to retransmit the same unacceptable segment indefinitely.
Consider this:

Sender:   SND.NXT = 1
          SND.UNA = 3
          SMSS = 2

Receiver: RCV.NXT = 3
          RCV.WND = 10

S: Seq 1 len 2  (Rxt 1)
R: (Seq < RCV.NXT, ignore)
S: Seq 1 len 2  (Rxt 2)
R: (ignore again)
:
:
S: (abort connection due to failure to progress)

On the other hand, correct behavior:

S: Seq 1 len 2  (Rxt 1)
R: (Seq < RCV.NXT) ACK 3
S: (update SND.NXT; send new data) Seq 3 len 2

Note that failing to emit some sort of acknowledgment leads to a
connection abort, whereas the acknowledgment in the second case can be
either a duplicate acknowledgment or new data carrying an ACK field.
The *only* time this matters is when the receiver has no data to send
in the reverse direction, or cannot send it, in which case it MUST
emit a duplicate acknowledgment for the sake of correctness.

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/d85edd28/attachment.bin