[e2e] Some questions about TCP.

[Detlef Bosau]

Hi again and first of all a happy new year to all!

At least for me, the discussion during the last weeks shed quite some 
light on my open issues.

Perhaps my basic misconception was, that DUPACKs are always are pure 
acks. Hence, when acknowledgements are sent piggyback with normal data 
packets, these ACKs are never considered as DUPACKs.

I was particurly pointed to the definition of a DUPACK as given in RFC 5681.

Now, some minor questions are still left.

1.: What is the correct behaviour of a TCP receiver when it receives 
data which is already acknowledged?

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.

Neither does the duplicate packet affect the receiver's cumulative 
acknowledgement counter, nor any indication for a pure ack is given.

So, the most appropriate behaviour is to simply ignore the packet.

With particular respect to SNOOP, this kind of understanding will render 
the DUPACK filtering unnecessary, because packet duplication does not 
cause DUPACKs.

Q: Is this correct?


2.: The RTO handling as defined in RFC 2988 does not specify a 
particular timer handling for TCP Reno.

However, to my understanding any pending retransmission timer should be 
canceled after having received three DUPACKs, because the fast 
retransmit algorithm includes a "Go Back N", hence _any_ 
_unacknowledged_ _data_ is retransmitted anyway and a still pending 
timer is likely to cause a premature timeout. So, it makes sense to me 
to cancel any pending timer in this case and hence start with a new 
timer upon the transmission of the next packet.

Q: Is this correct?

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.


Regards

Detlef

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