Wireless traffic stops when downloading large files at high speed: packets lost (Linksys WRT120N router)
- by Torious
The problem
Note: First I'd like to understand WHY this is happening. Ofcourse, a solution would be nice too. :)
When downloading a large file over HTTP at high-speeds, my wireless traffic basically stops: I can't open webpages and the download itself pauses. It pauses pretty much immediately after starting it; sometimes at 800 KB, sometimes at a few MB. After some time, the download (and other traffic) resumes, but the problem keeps reoccurring during the same download.
The problem does not occur when using a wired connection through the same router (Linskys WRT120N). Also note that the connection is not dropped when this happens. It's just that the traffic stops and I can't browse to web pages, etc. (SYN packets are sent but nothing is received, etc.)
Inspection with Wireshark shows that the following happens:
Server sends data packets which are acknowledged by client
Server sends a packet, but SEQ indicates some packets were lost (6 packets in one occurrence).
Server sends a few more packets and client acknowledges these using "selective acknowledgement"
Server stops sending data for a while (since the lost packets were not acknowledged or the router stops forwarding them?)
Eventually, server does a "retransmission" and traffic resumes as normal.
This all seems normal behavior to me when packet loss occurs. It's the consistent packet loss throughout a large, high-speed download that puzzles me.
What might cause this?
My own idea is the following: My internet is pretty fast (100 mbps), so when starting a large-file download, the router buffers the incoming data (since wireless introduces some slight delay / lower speed, in part due to other networks), but the buffer overflows and the router drops packets to regulate traffic (and because it has no choice).
But how could that happen? Doesn't the TCP window size limit the amount of data that can go unacknowledged? So how can the router's buffer overflow if there can only be like 64 KB waiting to be acknowledged?
Note: I've disabled TCP window scaling and dynamic window size through netsh options, in an attempt to fix this, but it doesn't seem to matter.
Also, Wireshark shows a pattern of the server sending 2 packets (of 1514 bytes) and the client sending an ACK, so does that rule out a possible buffer overflow? And a few more subsequent packets are received...
I'm at a loss here. Thanks for any insights.
Things that are (probably) NOT the cause / I have experimented with
The browser
Various TCP options in Windows 7 (netsh etc.)
Router settings such as MTU, beacon interval, UPnP, ...
