Forum Discussion

smp_86112's avatar
smp_86112
Icon for Cirrostratus rankCirrostratus
Nov 04, 2008

Maximum Segment Size

I've got an HTTP Virtual Server fronting a web server, which fronts a back-end application server. Clients connecting to the HTTP virtual server advertise a MSS of 1380. The LTM advertises a MSS of 1460 back to the client. The Proxy Maximum Segment Size option in the tcp profile is disabled, and the entire tcp profile settings are below. The same TCP profile is used on both the internal and external side of the LTM.

 

 

As the webserver pumps data from the app server back to the client, the MSS between the LTM and the webserver (the internal side) is 1460 bytes so the TCP window is full. However when the LTM passes this traffic back to the client (the external side), it splits the data into two segments - one full 1380 byte segment, followed by an 80 byte segment. This continues throughout the entire download.

 

 

My understanding of the Proxy MSS option is that if enabled, it will simply push the MSS value back to the webserver. At that point, I suspect the webserver will simply split the segments just like the LTM does - one full-size, and one smaller. Since I also suspect the LTM is more efficient at handling reassembly of TCP segments, I would like for the LTM to continue performing this operation.

 

 

Is there a way to configure the LTM to receive full 1460 byte segments on the internal interface, and send full 1380 byte segments to the client on the external interface - instead of splitting them into two separate segments?

 

 

profile tcp tcp {

 

reset on timeout enable

 

time wait recycle enable

 

delayed acks enable

 

proxy mss disable

 

proxy options disable

 

deferred accept disable

 

selective acks enable

 

ecn disable

 

limited transmit enable

 

rfc1323 enable

 

slow start enable

 

bandwidth delay enable

 

nagle disable

 

ack on push disable

 

md5 sign disable

 

md5 sign passphrase none

 

proxy buffer low 98304

 

proxy buffer high 131072

 

idle timeout 7200

 

time wait 2000

 

fin wait 5

 

close wait 5

 

send buffer 65535

 

recv window 65535

 

keep alive interval 1800

 

max retrans syn 4

 

max retrans 8

 

ip tos 0

 

link qos 0

 

}

 

3 Replies

  • Enabling Nagle's algorithm should do this: Nagle's attempts to limit the number of small segments on a network by buffering data until it receives the previous ACK.

     

     

    That being said, I have also seen Nagle's add noticeable latency to an application precisely because it is delaying sending data. According to the Wikipedia article on Nagle's (Click here) it sometimes interacts badly with Delayed ACKs. I have not tried disabling those with Nagle's enabled though.

     

     

    Also, I would create a new profile and leave the built-in tcp one at the default settings.

     

     

    Denny
  • Yeah, I specifically disabled Nagle because of it's interaction with Delayed Acks. And I have also seen latency improvements. But since it's not possible to disabled Delayed Acks on all the client platforms since we don't have any control over those, disabling Nagle was the only place to mitigate that problem.
  • I tinkered around a bit with the profile options. I found that by enabling "Proxy Maximum Segment Size" on the external side of the connection, the packets sent from the LTM to the client were full - 1380 bytes. This is with Nagle's algorithm disabled, and was my desired effect.

     

     

    I took tcpdumps on both sides of the LTM. The Proxy MMS setting resulted in the LTM informing the webserver that the MSS was 1380 - matching the client. But to my surprise, the webserver seems to be sending full-sized 1380 byte segments, instead of splitting them into one full and one small segment like the LTM does.

     

     

    Not sure I understand why, but this setting seems to have done the trick.