Forum Discussion

smp_86112's avatar
smp_86112
Icon for Cirrostratus rankCirrostratus
Aug 21, 2008

LTM TCP Window Size behavior

I have been battling with TCP window sizes for some time now in an effort to improve HTTP application responsiveness, especially for those on higher-latency networks (~100-300ms RTT). Just by trial and error, I was able to DRASTICALLY reduce the response time of a single operation in one of our apps from 10 minutes to 8 seconds - simply by tweaking a couple of parameters in the TCP profiles used by the Virtual Server.

 

 

So here I am battling another report of slow response in an application. I began by taking a tcpdump of a LAN-connected client and looking closer at the TCP windows sizes used by the LTM. The send and receive window sizes of the Client TCP Profile on the VS is 65535.

 

 

However in the trace, it is obvious that the LTM starts off with a VERY small window (~4K). I guess that in itself didn't strike me as unusual, since the window size increases as the conversation moves forward. What did surprise me is that the server sent almost 2 megabytes of data (~100 seconds into the conversation) before the window was fully opened. The receive window of the client was wide open from start to finish.

 

 

I have been tinkering with the TCP profile parameters in an effort to either force the window to be fully-open right from the start, or to at least increase it faster than it did in this case. But I haven't had any success.

 

 

Is this normal TCP behavior for TCP on an LTM?

 

 

The top pic is a comparision of the LTM window size (black) and the client (red) window size. The bottom chart is a graph of the amount of data (in bytes) sent from the server to the client.
config
design

3 Replies

Sort By
  • dennypayne's avatar
    dennypayne
    Icon for Employee rankEmployee
    Aug 22, 2008
    I have had the most luck with this type of issue by turning off Nagle's Algorithm, Bandwidth Delay, and Slow Start (which along with the buffer sizes are the primary settings changed in the default tcp-lan-optimized profile).

     

     

    Nagle's especially seems to be the culprit, because it tries to buffer small packets instead of immediately sending them on the wire, and delays ACK responses as well. Ostensibly, it is designed so as not to flood higher-latency networks with a bunch of small packets, but in practice it seems that it introduces a lot of latency even on long RTT networks.

     

     

    Denny
  • brianokelly_119's avatar
    brianokelly_119
    Icon for Nimbostratus rankNimbostratus
    Oct 17, 2011
    Hi guys, I have noticed the same behavior lately. Have you come across any other solutions to increase the window size quicker?
  • smp_86112's avatar
    smp_86112
    Icon for Cirrostratus rankCirrostratus
    Oct 17, 2011
    Hi Brian. I don't recall the specifics of what prompted this question, but I have learned much about LTM/TCP in the intervening years. One thing that I have learned which is pertinent to questions about the Receive Window is to understand which direction data is flowing. If I read my description again closely, it sounds like the data is flowing from server to client. And if that's the case, then I should not have expected the LTM's Receive Window to increase, because it is not receiving data - it is SENDING. And so it's the *client's* Receive Window which should be increasing quickly, not the LTM's. If the data was flowing in the opposite direction, i.e. the client was POSTing data to the server, THEN I would expect the LTM's receive window to increase. And believe me - it does.

     

     

    So in your case, is that the behavior you are asking about - the LTM's Receive Window does not open when sending data to the client? Or is the scenario a bit different? I am always interested in diagnosing TCP issues...