[e2e] Some questions about TCP.

[Detlef Bosau]

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.

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

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


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

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

The more I think about it, I tend to start a new RTO, because otherwise 
there is a high probability to stall the Reno recovery and to end up in 
an a Tahoe slow start...

But I'm eager to learn on this one, that's why I asked.

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


-- 
Detlef Bosau            Galileistraße 30        70565 Stuttgart
phone: +49 711 5208031  mobile: +49 172 6819937 skype: detlef.bosau     
ICQ: 566129673          detlef.bosau at web.de     http://www.detlef-bosau.de