[e2e] Some questions about TCP.

Detlef Bosau detlef.bosau at web.de
Tue Jan 19 07:53:05 PST 2010

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.

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

More information about the end2end-interest mailing list