Slow Response - host send a ACK packet slowly than usual

asked 2019-08-29 13:43:20 +0000

nimdrak gravatar image

I study the Behavior TCP and did a small experiment about TCP.

In the experiment, [10.0.0.1] host send a TCP flow to [10.0.0.2] host.

I found that a re-transmission occur. To find the cause, I used Wireshark.

The captured packets is the below. the two capture's reference time is different due to the different start time of Wireshark.

From the captured, I found that the [10.0.0.2] host send an ACK slowly than usual.

It makes [10.0.0.1] host send an re-transmission.

At first, I think it would be due to CPU utilization but it wouldn't when seeing it by htop command.

Is there any reason for [10.0.0.2] send a ACK slowly?

Could you give me a little hint for trouble shooting?

Thank you for reading.

<10.0.0.2 side>

1735203 51.249349738    10.0.0.1    10.0.0.2    TCP 1514    35250 → 50021 
[ACK] Seq=16124342 Ack=1 Win=58 Len=1448 TSval=902298 TSecr=902296

1735204 51.249349999    10.0.0.1    10.0.0.2    TCP 1514    35250 → 50021 
[ACK] Seq=16125790 Ack=1 Win=58 Len=1448 TSval=902298 TSecr=902296

1735205 51.249350340    10.0.0.1    10.0.0.2    TCP 866 35250 → 50021 
[PSH, ACK] Seq=16127238 Ack=1 Win=58 Len=800 TSval=902298 TSecr=902296

1735207 51.258283589    10.0.0.1    10.0.0.2    TCP 866 
[TCP Retransmission] 35250 → 50021 [PSH, ACK] Seq=16127238 
Ack=1 Win=58 Len=800 TSval=902301 TSecr=902298

1735208 51.258288919    10.0.0.2    10.0.0.1    TCP 66  50021 → 35250 
[ACK] Seq=1 Ack=16128038 Win=32766 Len=0 TSval=902301 TSecr=902298

1735209 51.258296563    10.0.0.2    10.0.0.1    TCP 78  
[TCP Dup ACK 1735208#1] 50021 → 35250 [ACK] Seq=1 Ack=16128038 
Win=32766 Len=0 TSval=902301 TSecr=902301

1736003 51.263706308    10.0.0.1    10.0.0.2    TCP 1514    35250 → 50021 
[ACK] Seq=16128038 Ack=1 Win=58 Len=1448 TSval=902302 TSecr=902301

1736004 51.263724813    10.0.0.2    10.0.0.1    TCP 66  50021 → 35250 
[ACK] Seq=1 Ack=16129486 Win=32766 Len=0 TSval=902302 TSecr=902302

<10.0.0.1 side>

1735214 58.247766104    10.0.0.1    10.0.0.2    TCP 1514    35250 → 50021 
[ACK] Seq=16125790 Ack=1 Win=58 Len=1448 TSval=902298 TSecr=902296

1735215 58.247766625    10.0.0.1    10.0.0.2    TCP 866 35250 → 50021 
[PSH, ACK] Seq=16127238 Ack=1 Win=58 Len=800 TSval=902298 TSecr=902296

1735216 58.247807101    10.0.0.2    10.0.0.1    TCP 66  50021 → 35250 
[ACK] Seq=1 Ack=16092486 Win=32766 Len=0 TSval=902298 TSecr=902298

1735219 58.257898525    10.0.0.1    10.0.0.2    TCP 866 
[TCP Retransmission] 35250 → 50021 [PSH, ACK] Seq=16127238 
Ack=1 Win=58 Len=800 TSval=902301 TSecr=902298 ...
(more)
edit retag flag offensive close merge delete

Comments

Can you share us a trace...

Sharing a trace FAQ

Christian_R gravatar imageChristian_R ( 2019-08-31 20:42:11 +0000 )edit

@Christian_R I will! Thank you so much for your comment :)

nimdrak gravatar imagenimdrak ( 2019-09-01 07:20:06 +0000 )edit

@Christian_Rhttps://www.dropbox.com/s/1mtgtv5xof6...https://www.dropbox.com/s/1mtgtv5xof6... These are the captured at each host. If you don't mind, please check these files.

nimdrak gravatar imagenimdrak ( 2019-09-01 07:42:12 +0000 )edit

I can't see from the question which ACK is more slowly than expected. But in general I would say that your trace file host2... is really not useable for a reliable analysis. As the delta time "time since previous captured packet" is often negative. Which means that you haven't captured in a proper way.

Christian_R gravatar imageChristian_R ( 2019-09-01 19:27:59 +0000 )edit