Subject: TCP receiver and Duplicate packets

From: Ronny Tittoto <[email-masked]>
Date: Thu, 28 Feb 2002 15:27:08 +0100 (MET)

Dear all,
I'm working on TCP performances over GPRS and UMTS networks.
I've observed a singular behaviour of TCP receiver in presence of
duplicate packets.
When a receiver receives a packet with sequence number equal to a packet
received before it reply with a duplicate ack.
For example:
- suppose the reciever has already received packets 1 to 40
- a packet with sequence number 35 arrives
- the receiver doesn't need this packet, it has already received it!
- the receiver reply with a multiple ack requesting packet 41.

My question is:
Why does the receiver replay when it receives an old packet already
received?
Is it an implementation need or a simplification?

Thanks a lot!
Best regards

Ronny   

._____________________________________________________________________. 
|Ronny Tittoto 380560/IL  [email-masked]                         |
|                         [email-masked]                   |
|---------------------------------------------------------------------|
|                                                                     |
|_____________________________________________________________________|

---

From: Philippe Ragon <[email-masked]>
Date: Thu, 28 Feb 2002 21:07:03 +0100

Ronny,

Sending a duplicate ACK in the case you are describing, is the specified 
behavior in TCP.
Imagine for example that all the ACKs generated by packets 35 to 40 have 
been lost, without the duplicate ACK, the sender would keep sending ACK 35 
until it decides that the connection is lost.
In your case (and I know it from experience in the same context) the 
repetition of packet 35 have probably been triggered not because ACKs have 
been lost, but because they arrived too late.
Without any additional information, such has the one conveyed by D-SACK 
(refer to RFC 2883), there is no way for the source to infer from this 
duplicate ACK that it has wrongly repeated packet 35 and undo what it has 
done (return to slow start, ssthresh lowering, ...) when it has thought 
that this packet was lost due to network congestion.

Quick and reliable detection of spurious re-transmission is an important 
feature in the GPRS context in order not to degrade performance. Such a 
subject should be advanced quickly in relevant IETF work group.

I hope that people will not infer from my reference to D-SACK that I 
consider it as the final say in term of spurious retransmission detection, 
and as a consequence, that I disregard the Eiffel algorithm that is 
currently under specification study in the 'tswg' work group.

Cheers,
Philippe Ragon

>Is it an implementation need or a simplification?

---------------------------------------------------------------------
Philippe Ragon / Tour Atlas / 10, villa d'Este/ 75013 Paris/ FRANCE
Telephone & Fax    : (33) 01 45 70 79 53
E-mail                   :   [email-masked]
---------------------------------------------------------------------