Why does pfSense set net.inet.tcp.delayed_ack to 0?
muppet last edited by muppet
I ask only for my own interesting/understanding.
FreeBSD 11.2 by default sets this to 1, but pfSense sets it to 0.
The only real detail I can find about it is from the FreeBSD tuning man page:
"The net.inet.tcp.delayed_ack TCP feature is largely misunderstood. Historically speaking, this feature was designed to allow the acknowledgement to transmitted data to be returned along withthe response. For example, when you type over a remote shell, the acknowledgement to the character you send can be returned along with the data representing the echo of the character. With delayed acks turned off, the acknowledgement may be sent in its own packet, before the remote service has a chance to echo the data it just received. This same concept also applies to any interactive protocol (e.g., SMTP, WWW, POP3), and can cut the number of tiny packets flowing across the network in half. The FreeBSD delayed ACK implementation also follows the TCP protocol rule that at least every other packet be acknowledged even if the standard 100ms timeout has not yet passed. Normally the worst a delayed ACK can do is slightly delay the teardown of a connection, or slightly delay the ramp-up of a slow-start TCP connection. While we are not sure we believe that the several FAQs related to packages such as SAMBA and SQUID which advise turning off delayed acks may be referring to the slow-start issue."
It would seem to me from the section I've bolded (and this is where I want to learn why I'm wrong) that it wouldn't be a bad thing to have it set to 1. It would create less traffic when SSHing or managing the Firewall via HTTP/HTTPS/HTTP2.
To be clear, I understand it doesn't affect traffic routing through the pfSense
So do any longterm pfSensers know what the reason/rationale for setting it to 0 is?
It was set that way initially back in 2005: https://github.com/pfsense/pfsense/commit/df9f94d67bdaf298f046d1bc6e430756eb6a6dea
This site has some insight into why you might not want it: https://calomel.org/freebsd_network_tuning.html
# By default, acks are delayed by 100 ms or sent every other packet in order to # improve the chance of being added to another returned data packet which is # full. This method can cut the number of tiny packets flowing across the # network and is efficient. But, delayed ACKs cause issues on modern, short # hop, low latency networks. TCP works by increasing the congestion window, # which is the amount of data currently traveling on the wire, based on the # number of ACKs received per time frame. Delaying the timing of the ACKs # received results in less data on the wire, time in TCP slowstart is doubled # and in congestion avoidance after packet loss the congestion window growth is # slowed. Setting delacktime higher then 100 will to slow downloads as ACKs # are queued too long. On low latecy 10gig links we find a value of 20ms is # optimal. http://www.tel.uva.es/personales/ignmig/pdfs/ogonzalez_NOC05.pdf #net.inet.tcp.delayed_ack=1 # (default 1) #net.inet.tcp.delacktime=20 # (default 100)
So it might have helped at one time to set it
=1but on modern networks
You can change the tunable if you believe it would help your network, but the default is still good.
muppet last edited by
Thank you, that makes sense, I am enlightened!
Appreciate the reply.