Dan Hartmeier's article on selective ACK prioritization producing better performance on async circuits is extremely interesting. His explanation focuses on OpenBSD's pf/ALTQ traffic filter/QoS framework, but the concept escapes the examples. Once I have the time to stick QoS code on my firewall, I will absolutely be implementing the core concept, which is prioritization of TCP ACKs over other traffic, which sign Dan Hartmeier‘s article on selective ACK prioritization producing better performance on async circuits is extremely interesting. His explanation focuses on OpenBSD’s pf/ALTQ traffic filter/QoS framework, but the concept escapes the examples. Once I have the time to stick QoS code on my firewall, I will absolutely be implementing the core concept, which is prioritization of TCP ACKs over other traffic, which significantly improves TCP application performance across most ADSL and cable broadband links. The reasoning is simple: A session cannot continue until an ACK from the receiver is seen by the sender, confirming that the last batch of packets were received. When a low-bandwidth upstream link is saturated, the ACKs are delayed, and TCP performance through the high-bandwidth downstream link suffers. Since the idea is so simple, and the implementation isn’t very challenging, why don’t we see this as a selectable option in SOHO firewalls? They could even market it as Turbo Mode! or similar.