tcp error control problem

Question

in this capture file there is strange problem http://www.mediafire.com/download/ouaxioxglpogd0z/FDR_7_9613.pcap

i have two devices one called FDR with ip 105.181.145.115 only sends data to the server with ip 41.32.98.66

in case of packet drop FDR sends retransmission packet why ???

Answer 1

What I know out of the trace is that the trace is taken on the server.
So from that point I only can talk clear about the server. And I can only asume what the client sees. Because I see only the client packets that reach the server. I asume that the client is a few hops (router) away from the server, because the TTL is at 45 in the client packets.

It is clear that there are some errors between the server and the client. Packet Loss, Out of Order,... -> Maybe this is due to an instable network, bottlenecks, or ...

But if I understand your question right than this all is not your question. Right? You want to know why there is the "DUP ACK" in FRAME 17, for example. For the answer I must start in FRAME 7: There is a PACKET with SEQ=111 and LEN=55 wich arrives the server. Afer that the server receives more segments in correct order until FRAME 16. In FRAME 16 he receives the same SEGMENT as he has seen in FRAME 7, but he has received so far Segements till 275. And he is expecting 276. So as an respond to FRAME 16 the server sends in FRAME 17 the ACK with the next expected SEQ number 276. Later in the trace behaviour is still there, but with a few more events around. alt text

Answer 2

I don't think that we face a real packet loss problem here.
The problem is more a combination of the 200ms delayACK timer of the windows server, the nature of the traffic sending 55 bytes every 100ms and the FDR dropping its RTO below 200 ms.

Traffic Pattern indicating that the FDR tries to send 10 55-bytes records within 1 second:

       MMDDYY hhmmss no 
..1113 032914 122001  1 49.4100 49.4087 054.5200 2.9043
..1113 032914 122001  2 49.4111 49.4093 054.5200 2.5333
..1113 032914 122001  3 49.4108 49.4094 054.5090 2.1621
..1113 032914 122001  4 49.4089 49.4086 054.5200 1.7907
..1113 032914 122001  5 49.4087 49.4095 054.5200 1.4194
..1113 032914 122001  6 49.4063 49.4080 054.5090 1.0479
..1113 032914 122001  7 49.4073 49.4090 054.5090 0.6764
..1113 032914 122001  8 49.4073 49.4082 054.5090 0.3046
..1113 032914 122001  9 49.4090 49.4083 054.5200 6.2159
..1113 032914 122001 10 49.4110 49.4092 054.5090 5.8447

So if everything runs smoothly, we should see a 55 byte (single) segment arriving at 10 0ms intervals.
A single segment is not enough for the windows TCP stack to send an ACK right away so we wait for the next segment to arrive or for the 200 ms delayAck timer to expire, whatever occurs first.
The trace shows that the retransmission timeout in FDR drops below 200 ms which will cause the spurious retransmissions that you see.
So in order to fix this problem (if it still needs fixing after more than a year...) would be to turn off delayed acknowledgements in windows TCP. alt text