Forum Discussion
smp_86112
Cirrostratus
CirrostratusMaximum 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
}
- dennypayne
Employee
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 
smp_86112Yeah, 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.- smp_86112I 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.
