This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Duplicate ACK Causing Client Slowdown?

0

I'm working on troubleshooting a slow application. I took a few packet captures from the client workstation and I'm seeing some odd behavior with duplicate ACKs that I can't seem to explain. You can see in the screenshot below that the server (172.) is occasionally sending a duplicate ack to the client (10.). After the duplicate ack the client seems to hang for a random amount of time before moving on to the next HTTP request. Usually always more then a second but I have seen some as high as 20 seconds.

I'm a bit new to analyzing sequence and acknowledgement numbers so feel free to correct me here. But I think the reason for the duplicate ack being sent is because the server is not receiving the ack from the client in frame 90. I'm just not sure why this would cause the client to grind to a halt.

Packet Capture Download - Truncated to 79 bytes.

asked 08 Jul '14, 13:58

Strebzilla's gravatar image

Strebzilla
16114
accept rate: 0%

edited 09 Jul '14, 09:01

2

Hi,

it's a bit hard to do packet analysis based on screenshots, so can you please post a capture file somewhere (google drive, dropbox, cloudshark.org) and post the link here? If you have privacy concerns, you can anonymize the capture file with Tracewrangler, which is developed by our member @Jasper.

BTW: Why are you hiding private addresses in your screenshot (10.x.x.x and 172.x.x.x)?? O.K. the 172.x.x.x could be public addresses....

Regards
Kurt

(08 Jul '14, 18:05) Kurt Knochner ♦

Thanks for the tip. I see your point about the private addresses. It's nothing super secret but people get a bit freaked about privacy here. I'll update this post asap.

(08 Jul '14, 18:10) Strebzilla

I'm sorry to tell you, but you removed too data much from the payload. I can't even identify any HTTP requests. With that capture file it's even harder to do analysis than with the screenshot your removed ;-))

(09 Jul '14, 08:05) Kurt Knochner ♦

Sorry. This is clearly my first crack at soliciting help from the community so bear with me while I get it right. I cleaned out everything after layer 4 because I didn't think it was necessary since the duplicate ack seemed to be causing the slowdown and not http. I really can't make too much of the payload public so is there a reasonable place I can truncate the capture and still make it useful?

(09 Jul '14, 08:20) Strebzilla

so bear with me while I get it right.

Don't be afraid, this is a friendly site with patient members ;-)

I really can't make too much of the payload public

I understand that.

so is there a reasonable place I can truncate the capture and still make it useful?

That's the tricky part. We would need more information than you want to disclose, to get an idea where the problem might be. Can you try to keep at least 15-20 bytes of the TCP payload, which would contain the HTTP method and some bytes of the URL. I'm not sure if that is sufficient to do any analysis, but we can start with that.

(09 Jul '14, 08:24) Kurt Knochner ♦

Your patience is much appreciated :-)

79 Bytes seems to be a good sweet spot to get a unique URI.

(09 Jul '14, 09:02) Strebzilla

O.K. I think we can work with the latest capture file. Where do you think there could be a problem? Please post the frame number and your assumption.

BTW: What kind of application is this? Is it an interactive application that needs to wait for input from the user, or something that should do things automatically as fast as possible?

(09 Jul '14, 09:25) Kurt Knochner ♦

The suspected problem occurs multiple times in the capture but tcp stream index 2 has the most extreme example. Packet 96 is a duplicate to the ack in frame 89. The next packet, number 97, doesn't get sent for 20.895 seconds. I suspect this is what's causing trouble for users. You can see more examples at packets 191, 253, 564, etc.

This seems to be occurring in all of the tcp streams with delays ranging from 1-20 seconds. I realize that you could see this kind of delay while waiting for user input but the fact this always happens after the duplicate ack strikes me as odd.

It's an interactive web application. Users pull up records, make updates, create new records, etc.

(09 Jul '14, 10:28) Strebzilla
showing 5 of 8 show 3 more comments

One Answer:

1

I don't think the DUP-ACK is the problem, because there are other delays in stream #2 that are not accompanied by a DUP-ACK.

Frame #1455: There is a 37 second delay for the next GET.
Frame #2305: There is a 34 second delay for the next POST.
Frame #2672: There is a 11 second delay for the next GET.

There is no explanation in the capture file for that delay, maybe waiting for the next user action.

That's the reason why I was asking for the type of the application (interactive versus 'automatic'), as it does not only happen after a DUP-ACK.

It's an interactive web application. Users pull up records, make updates, create new records, etc.

O.K. then we would need a much more detailed problem description.

  • What exactly is slow?
  • When (timestamp in the capture file) did the user report the problem?
  • etc.

If you don't have that information, you should repeat the tests and collect (at least) the following information:

  • when does the problem occur - time on the capturing device - to the second!
  • which action was initiated in the web app (click on which link)
  • what was the expected result
  • what was the observed result
  • how much data should have been transmitted (estimation)
  • what exactly is the 'problem'
  • whatever else helps to nail down the problem

Regards
Kurt

answered 09 Jul '14, 10:48

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

edited 09 Jul '14, 10:55

A lot of that information I don't have. I've been working with our application team on this issue so I'd need to get that from them. My suspicion is that this has something to do with the application itself or the back end database. I just wanted to make sure those duplicate acks weren't something noteworthy which you have just confirmed.

Thanks so much for looking into this to me and for helping me get a usable packet capture to you.

(09 Jul '14, 12:34) Strebzilla

I just wanted to make sure those duplicate acks weren't something noteworthy which you have just confirmed.

actually I did not want to 'confirm' that. What I wanted to say: There is not enough information about the problem to figure out what's going wrong. It could be related to the DUP-ACK (although I don't believe that), it could the something totally different. So, the best thing you can do, is to collect the information I listed above and then come back for further analysis.

Thanks so much for looking into this to me

You're welcome!

(09 Jul '14, 13:08) Kurt Knochner ♦