Investigating the LTM TCP Profile: Nagle’s Algorithm
Introduction
The LTM TCP profile has over thirty settings that can be manipulated to enhance the experience between client and server. Because the TCP profile is applied to the virtual server, the...
Updated Nov 30, 2023
Version 3.0
JRahm
Admin
AdminJRahmAdmin
Admin
L4L7_53191
Nimbostratus
NimbostratusNice write up Jason, as usual. One note - the real big issue with Nagling is that delayed ACK problem.
Check out line 5 of the algorithm above. The line "if there is unconfirmed data still in the pipe" is the specific bit that doesn't play well with delayed ACKs: if there's an ACK outstanding Nagle will buffer. If it gets one, it'll immediately send the data. But now, you've got delayed ACK waiting for data before it sends an ACK! Then you're stuck - you're buffering on the send side (Nagle), but waiting for that delayed ACK timer to fire on the receive side.
Also, that delayed ACK timer is set on bootstrap and it can fire at any time between 1-500ms (RFC states no more than 500) when the ACK is being delayed on the receive side. So you may not get totally clean and predictable stalls - you'll just know that it's not performing well.
One last bit, regarding BigIP. If you disable Nagle, you may also want to enable "Acknowledge on Push" and test. I've seen dramatic improvements when these are done together...
--Matt