Should delayed ACKs be enabled by default?

[Mark Felder]

John Nagle recently commented on a HN post[1] regarding the issues
delayed acks cause. Has this been studied in depth on FreeBSD?

His post:

> That still irks me. The real problem is not tinygram prevention. It's
> ACK delays, and that stupid fixed timer. They both went into TCP around
> the same time, but independently. I did tinygram prevention (the Nagle
> algorithm) and Berkeley did delayed ACKs, both in the early 1980s. The
> combination of the two is awful. Unfortunately by the time I found about
> delayed ACKs, I had changed jobs, was out of networking, and doing a
> product for Autodesk on non-networked PCs.
>
> Delayed ACKs are a win only in certain circumstances - mostly character
> echo for Telnet. (When Berkeley installed delayed ACKs, they were doing
> a lot of Telnet from terminal concentrators in student terminal rooms to
> host VAX machines doing the work. For that particular situation, it made
> sense.) The delayed ACK timer is scaled to expected human response time.
> A delayed ACK is a bet that the other end will reply to what you just
> sent almost immediately. Except for some RPC protocols, this is
> unlikely. So the ACK delay mechanism loses the bet, over and over,
> delaying the ACK, waiting for a packet on which the ACK can be
> piggybacked, not getting it, and then sending the ACK, delayed. There's
> nothing in TCP to automatically turn this off. However, Linux (and I
> think Windows) now have a TCP_QUICKACK socket option. Turn that on
> unless you have a very unusual application.
>
> Turning on TCP_NODELAY has similar effects, but can make throughput
> worse for small writes. If you write a loop which sends just a few bytes
> (worst case, one byte) to a socket with "write()", and the Nagle
> algorithm is disabled with TCP_NODELAY, each write becomes one IP
> packet. This increases traffic by a factor of 40, with IP and TCP
> headers for each payload. Tinygram prevention won't let you send a
> second packet if you have one in flight, unless you have enough data to
> fill the maximum sized packet. It accumulates bytes for one round trip
> time, then sends everything in the queue. That's almost always what you
> want. If you have TCP_NODELAY set, you need to be much more aware of
> buffering and flushing issues.
>
> None of this matters for bulk one-way transfers, which is most HTTP
> today. (I've never looked at the impact of this on the SSL handshake,
> where it might matter.)
>
> Short version: set TCP_QUICKACK. If you find a case where that makes
> things worse, let me know.
>
> John Nagle


[1] https://news.ycombinator.com/item?id=10608356



-- 
  Mark Felder
  ports-secteam member
  feld at FreeBSD.org