Slow file copying to site usings Windows SMB over MPLS circuit

[Steve_Ballantyn]

Hello folks,

This is not necessarily an Extreme Networks specific question, but I am hoping the community here can give me a clue about a problem that I have exhausted myself on.

I have a remote site which is connected to my home office using a Spectrum MPLS circuit (20Mbps). When *downloading* a file to a client PC from the home office, the speed is around 512KBps. At times, it will leap to 700KBps and then immediately drop. There are also long pauses before the transfer starts. And there are several pauses during the transfer. If I upload that same file to that same server, the speed is 2MBps (what is expected).

Some facts about the issue:

1. A simple speed test indicates I am getting a full 20Mbps in both directions.
2. Downloading a file using FTP, I achieve full speed.
3. Downloading anything from the Internet - I achieve full speed.
4. I have verified speed and duplex settings on the interfaces which connect the two sites, and they are fine.
5. I have uninstalled the Antivirus software on the client, with no change.
6. Downloading while connected to my Extreme Networks wireless access point at this site - I achieve full speed!?!? 
7. Lowering the MTU of the client had no effect (I played the game of ping -f to find the 'perfect MTU value'). Although I found that the native MTU it was choosing for the file transfer was 1514 (while the MPLS circuit is 1500).
8. The switch at the site is an old Cisco Catalyst. I have exchanged that switch with a known good spare which had no effect.
9. I have replaced all the cables with brand new Cat6e cables, which had no effect.

I am going to try and attach some Wireshark captures demonstrating a "fast" and then a "slow" transfer. The difference is that the fast transfer was achieved on wireless, and the slow transfer was while connected via physical cable to the switch.

Here is a SLOW file transfer: CLICK ME
Here is a FAST file transfer: CLICK ME

[Jarek]

Hmmm... I think you can also try to disable Large Send Offload (LSO) (on client) and check again. You can find this option in network card -> advanced tab.

--
Jarek

[Steve_Ballantyn]

Hello Stephane - that's the funny part of it. No, the AP is connected to the same switch that all the workstations are! Now you can see what is so frustrating about this.

When the client is traversing the encapsulated WASSP protocol on the AP, it seems to shake this issue of slow SMB/CIFS transfers.

I am tempted to install VPN tunnel. Or a GRE tunnel. I really think that it's the nesting of the CIFS protocol that "fixes" this issue.

[Stephane_Grosj1]

The problem here, is that it works when connected to an AP. Is that AP connected to a different switch?

[Erik_Auerswald]

Hi Steve,

that sounds a bit like bufferbloat to me.

Manually forcing the TCP window too high could create congestion. Together with too much buffering (perhaps even a well-meaning shaper configuration) this would result in lots of TCP segments being tail-dropped after the bottleneck's too large buffer eventually does fill.

Even with dynamic TCP window sizes bufferbloat will result in just what you have seen: high throughput, followed by stalling, and again from the start.

You can work around bufferbloat in the WAN by policing traffic entering the WAN to just below the bottleneck bandwidth (or configured shaper rate) and apply AQM or QoS on your equipment.

You can test the WAN's buffer depth by sending a steady stream of UDP packets and observing the additional delay added by buffering of excess traffic. See e.g. my notes about bufferbloat experiences for ideas. Testing that might help you rule out this specific issue as well, of course.

Thanks,
Erik