[e2e] Some questions about TCP.
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
>> 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
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.
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