TCP duplcate ACK behaviour

I have narrowed down a performance issue but am trying to understand the TCP behaviour that I am seeing:
 ( I have changed the IPS)


So I see the receiver respond with an ACK 35515097 which is as expected. However directly after a window update the receiver starts to send duplicate ACKS for the same segment that it acknowledged in the first packet.

Why would it send a duplicate ACK if it already sent an TCP prior saying it received that segment?  There were many Out of order packets, so my first thought was that due to the TCP behavior of sending these packets to the buffer with a gap, eventually after receiving so many it would have to drop some and could cause this. TCP will not deliver OUT OF ORDER packets to the process/application (FTP here)  so if it received to many packets it would not be able to buffer all of this without some discard. The only issue with this theory is I would expect to see zero windows coming from the receiver if that was the case, which I do not.

I can see there is latency across the link between these 2 hosts as a fast transmit that is sent from sender does not get to receiver for 4 secs at times. I am just trying to understand 2 things:
Why the duplicate ACKS after the receiver says it received that segment

Why at times I will see a Fast Retransmit after 4-7 duplicate ACKS when it should be after 3?





No.     Time        Source                Destination           Protocol Info
  38130 180.317208  1.1.1.1         2.2.2.2         TCP      65519 > 42397 [ACK] Seq=1 Ack=35515097 Win=65160 Len=0 TSV=3909745777 TSER=3175776381

No.     Time        Source                Destination           Protocol Info
  38131 180.317308  1.1.1.1         2.2.2.2        TCP      [TCP Window Update] 65519 > 42397 [ACK] Seq=1 Ack=35515097 Win=66608 Len=0 TSV=3909745777 TSER=3175776381 SLE=35516545 SRE=35517993


No.     Time        Source                Destination           Protocol Info
  38133 180.317329  1.1.1.1        2.2.2.2        TCP      [TCP Dup ACK 38131#1] 65519 > 42397 [ACK] Seq=1 Ack=35515097 Win=66608 Len=0 TSV=3909745777 TSER=3175776381 SLE=35516545 SRE=35517993


thanks
LVL 1
andrew_89Asked:
Who is Participating?

[Webinar] Streamline your web hosting managementRegister Today

x
 
rfc1180Connect With a Mentor Commented:
>Why at times I will see a Fast Retransmit after 4-7 duplicate ACKS when it should be after 3?

It is related all to timing, and is why the Operating System must be optimized for TCp of high latency links. The concept is that TCP will generate an immediate acknowledgment (a duplicate ACK) when a segment has been received out- of-order; with this being said, this duplicate ACK should not be delayed. For the sake of others reading this, the purpose of the duplicate ACK is to let the other end know that a segment was received out of order, what the sequence number of that segment was. Now an application is only has smart as the programmer, obvouisly with some algorthyms that enhanced the protocol, but TCP is far from a perfect protocol. What I mean by this is that TCP does not know whether a duplicate ACK is caused by either a lost segment or by the reordering of segments; TCP will wait for a small number of duplicate ACKs to be received. It is also assumed that if there is just a reordering of the segments, there will be only one or two duplicate ACKs before the reordered segment is processed, which will then generate a new ACK; however,  If three or more duplicate ACKs are received in a row, there is high probability that a segment has been lost. TCP then performs a retransmission (Without waiting for a retransmission timer to expire) of what appears to be the missing segment.

Billy
0
 
andrew_89Author Commented:
sorry for delay
0
All Courses

From novice to tech pro — start learning today.