Re: TCP Windowing over WAN

apaxson · ‎06-18-2006

Hey experts! I'm building a network enhancement project on my network to deal with the growth over the last 12 months for better traffic efficiency.

Right now, I'm trying to determine the best TCP window sizes on my servers. I can build the window sizes to match my WAN links, but then, my LAN connections to the servers will suffer.

If I modify my TCP Window to my LAN connections, my WAN routers will be overwhelmed with lots of dropped packes.

I realize the window will "slide" to an appropriate level over my WAN, but that is alot of unnecessary traffic and CPU on the router and it's interfaces until the window size is at an appropriate level to sustain.

Is there a better way to handle this?

Have any of you gone through this before?

Thanks!!

leonvd79 · ‎06-18-2006

Hello,

If you are looking for a solution to use your WAN link more efficiently, QoS will provide the solution.

For instance traffic shaping can smooth bursty traffic on your WAN link by queueing packets.

I do not think you should modify TCP windowing as it is dynamic by nature.

I suggest you start with defining your bandwidth requirements per application and map that to a quality of service policy.

For configuration examples and documentation use the Cisco Documentation site http://www.cisco.com/univercd/cc/td/doc/product/software/ios124/124cg/hqos_c/index.htm

HTH

Leon

* Please rate posts.

apaxson · ‎06-19-2006

QoS will certainly help, when trying to load balance the data traffic. However, QoS will only help the traffic on the line. If the Operating System is only sending throttled traffic, then QoS will have little bearing.

The problem is, out-of-the-box operating systems ship with a default setting, that is too generalized. You really *should* "tune" the network settings of the OS to your network according to your network specifications and applications.

I agree with you, that TCP Windowing is dynamic by nature. But, only to it's maximum size, then it "slides" down, until both systems agree on the data. If I already know how much the systems can talk, then I can *help* them use a higher throughput.

Using your bandwidth, delay, and application requirements, you can "tune" your servers for more efficient networking. Once you do that, you use QoS to help prioritize the traffic between many systems "on the line". Microsoft, Sun, RedHat, etc, do not know your network, so they "ship" with a default setting, that works across all kinds of networks.

For example, the maximum TCP Windows for certain OS's are:

OS: FreeBSD

Default TCP Buffer: 16kB

Maximum TCP Buffer: 256kB

OS: Mac OSX

Default TCP Buffer: 32kB

Maximum TCP Buffer: 256kB

OS: Windows 2000/XP

Default TCP Buffer: 8kB

Maximum TCP Buffer: unknown

Data Resource: http://www.psc.edu/networking/projects/tcptune/

At best, FreeBSD will only send 256kB, even though you have a 1.5Mbps link