Small Window Size and Scaling when connection to application is SD-WAN

marmormi
New here

Small Window Size and Scaling when connection to application is SD-WAN

Hello,

We are experiencing an issue that impacts heavily the performance of some applications.
When client connected using SD-WAN technology the negotiation of the TCP shows the client:
Window: 512
Window Size Scaling: -1
And server:
Window: 141
Window Size Scaling: -1
Info extracted from handshake in the packet capture.
This is negotiated in an https socket with TLS 1.2.

When client connect using a different connection such as MPLS or even VPN-SSL client of a laptop and a public internet connection, window and scaling moves to higher values.
Bandwidth problems are discarded, local bandwidth is good and it happens to all sites and concentrator is also fine with no kind of overutilization.
This makes the application really slow when using Meraki SD-WAN.
Is there any factor I can check that forces this values?

Thanks

4 Replies 4
GIdenJoe
Kind of a big deal
Kind of a big deal

Where did you take the captures?  Do you have a capture at the source (the client and/or server) and another capture inside the tunnel?  Usually your client and the server determine their own window sizes and the network gear in between should not change these values.
You could have maximum segment size manipulation but this should not affect your TCP receive windows.

Hi, captures are on the ethernet card of the laptop as well as in the Meraki MX device. I have no screenshots of the server side itself but on the Meraki vMX where it is connected too.

I understand that client/server determine window size but this situation only happens with Meraki SD-WAN, not with MPLS either laptop vpn-ssl.

I have no size manipulation of MTU or MSS, which I also investigated making different test forcing other values, but it kept with the low performance.

PhilipDAth
Kind of a big deal
Kind of a big deal

You can get this happening with asymmetric circuits (more specifically, asymmetric response times).

 

Try enabling timestamps on both the server and client, and see if this improves the situation:

 

netsh int tcp set global timestamps=enable 

 

 

Is the SD-WAN running over the same circuit as the MPLS that you are using for testing or different circuits?

Thanks for the idea I will try to test, I need to ask the responsible for the server to do that. I will revert once I test.

 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels