He's referring to ACK compression, the idea that you
wait to ACK every two full-sized segments.
ACK compression is independent of slow-start, though
how you ACK determines how fast the other end of the
window opens. HOWEVER, that affects performance only when
the RTT*BW is nearly the same as the transfer size (filesize) -
where batch applications like FTP typically don't apply.
Further more, most TCP stacks are configured to ACK every OTHER packet.
Changing to ACK every fifth packet slows the windowsize growth,
so for large RTT*BW or short transactions (HTTP, even persistent,
given slow-start restart), performance _IS_ significantly affected
by doing this. Also, this increases the perceived RTT (since you
wait to get the 5th ACK to know you got anything), increases the
effect of return-path losses (if the ACK is lost, you're dead for
5 packet times), and increases the burstiness of the transmitter
(bursts of 6+ packets, rather than 3).
Supercomputer jocks want it - it reduces the thrashing between
send and receive processing, and reduces the ACK processing overheads
on both ends. However, satellite jocks, short-transaction (HTTP)
jocks, lossy-networks (wireless) jocks, and 'the rest of us' tag it
as a "really bad idea".
(I'll withhold comments correlating happiness with the TCP
knowledge of others for now :-)
Joe