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

TCP window size reducing

0

Background: I am trying to work out why LiveDrive, on my newly installed 80/20 connection is only uploading at a suspiciously round 256 KB/s. SpeedTest.Net shows ~60Mbps download and 19.2Mbps upload. My provider, PlusNet, suggested using Wireshark to check what packets are being transmitted to see if their traffic management system is throttling transmission.

Wireshark is showing that I am receiving a lot of 'batched' ACKs from the LiveDrive server where the Win value is reducing from, as an example, 64256 down to 1024 in 25 ACKs. (The window scaling factor is 256 and so the Window size value is dropping by 10 in each packet - 251,241 ... 24,14,4).

I am a novice at this sort of thing but having had a quick browse in the forums, it would appear that the receiving computer is maybe struggling to process the data quick enough and telling my computer to stop sending packets so quickly.

Is this a reasonable interpretation? Is there anything else I should check? Is 256KB/s being 1/4 MB/s just a cnincidence?

Any help gratefully received.

Cheers Simon

asked 31 Jan '14, 02:00

simmotech's gravatar image

simmotech
16113
accept rate: 0%

is it possible to post the capture file somewhere (google drive, dropbox, cloudshark.org or mega.co.nz)?

(31 Jan '14, 04:35) Kurt Knochner ♦

Wow - cloudshark.org is great!

I have uploaded a 10 second sample (is that enough?) as http://cloudshark.org/captures/bf0e4ffc577c

If anything the Window Size is smaller than before. I am sure I have seen 64K windows and >100KB windows in the original trace but now the largest seems just a few hundred bytes.

(31 Jan '14, 05:01) simmotech

2 Answers:

1

I'd say the problem is the https server who is taking too long to read the data from the socket, probably due to a dispatching problem at the server side. So your first assumption " it would appear that the receiving computer is maybe struggling to process the data quick enough and telling my computer to stop sending packets so quickly." seems to be correct.

The major delay is in the window_updates getting back to the client allowing it to continue sending data. See frame.time_delta gt 0.1 alt text

answered 02 Feb '14, 03:11

mrEEde's gravatar image

mrEEde
3.9k152270
accept rate: 20%

Thanks Kurt but I think this is the best answer.

As it turns out, LiveDrive seems to have 2 "Pro" profiles - the older one which I am on and a newer one. Mine seems to direct traffic to 82.129.64.210 which seems too slow to process packets quickly enough although it is still suspicious that the throughput is exactly 1/4 MB/s.

I got a temporary, free trial subscription, as suggested by LiveDrive support, with the 'newer Pro' profile. Changed the software to use this and instantly got 2.2MB/s upload which is spot on for my ~19.2Mbps upload bandwidth! Traffic was going to a different server at 82.129.64.250 and that seemed to be the only difference. I have a ticket with LiveDrive to change my profile and/or server to the faster one.

Thanks all.

(02 Feb '14, 03:30) simmotech

0

O.K. according to the capture file: there is something wrong. Well, I guess that's no real news for you ;-))

There are only a few 'DUP ACK' and 'Retransmission', not enough to explain any problems. The Window Updates (with the very low window sizes) are certainly a problem. However, you cannot deduce the reason for that from the capture file content.

So, what happens if you upload a file to a different system (dropbox, google drive, wetransfer.com, mega.co.nz) at the same time, while you upload something to LiveDrive? Same behaviour?

If no: The problem is LiveDrive (or something on the way to them), and you can try to complain at their support helpdesk in Pakistan (no offense, if you are from Pakistan) ;-)

If yes: Well, then it's getting interesting. Then it could be:

  • your local client (some AV software on the client interfering with the data stream, faking the window size for whatever reason)
  • your local network/router/firewall
  • your ISP link (some WAN 'optimization' taking place)
  • the 'internet' peering of your ISP
  • the internet infrastructure in your country
  • extraterrestrial solar radiation flipping bits somewhere
  • a broken NSA device, that interferes with your data stream
  • etc.

None of them, except the local problems, will be easy to troubleshoot just by looking at capture files (sorry!), because you will only see the effect of a problem, but you won't be able to figure out where it happens and why.

Regarding the NSA: You could try to call them first. They will certainly know if there are currently any larger problems on the internet as they are sitting in every internet router anyway, and on most server of the large internet companies too.....

Wait a moment: THAT could be an additional business model for them.

Global internet troubleshooting. Delivered by the experts of the NSA iWatch team (tm).

You report a problem. They fix it and book an appropriate amount of money (what they consider appropriate) from any of your known banking accounts.

Regards
Kurt

answered 31 Jan '14, 06:07

Kurt%20Knochner's gravatar image

Kurt Knochner ♦
24.8k1039237
accept rate: 15%

your ISP link (some WAN 'optimization' taking place)

Plusnet do employ "traffic management" so that may be a cause. I left them a couple of years ago due to their traffic management making peak time internet use almost impossible.

(31 Jan '14, 06:28) grahamb ♦

I now have a much large capture file (5 minutes worth, 175MB). Since Cloudshark can't accept a file that size, I tried uploading it to my LiveDrive portal (I have no prior experience with this). Apparently it used XXX.livedrive.com/portal/Uploader.php and this Flash Uploaded (there was a Java Uploader option). Doing that I got 811KB/s upload at the same time as the other backup which is much better!

The file can be seen at http://simmotech.livedrive.com/item/851b8859a1a842edb18cf04af6a908db (or just simmotech.livedrive.com)

With this capture I did Statistics/IO; changed the Y Axis unit to Bytes/Tick and set Smooth to M.avg 16. This produced a very clear, virtually flat line.

I also tried the Analyse/Expert Info and that showed 266 "Malformed TCP: New fragment overlaps old data (retransmission?)" errors. Further, there were a lot of "TCP: ACKed segment that wasn't captured (common at capture start)" and they were spread throughout the capture (ie not at the start)

I am beginning to wonder if it is PlusNet's traffic management that is slowing me down. How would they actually do that? I don't think they would send made-up ACKs to my PC would they - it would appear that that might do the trick!

(31 Jan '14, 06:32) simmotech

How would they actually do that?

By

  • faking window size updates
  • holding back data frames
  • holding back ACKs
  • dropping frames

There are many ways to 'shape' traffic ;-)

(31 Jan '14, 06:37) Kurt Knochner ♦