Hello!

Of course, number of ACK increases. It is the goal. :-)

unpleasant increase in service demands on something like a "burst 
enabled" (./configure --enable-burst) netperf TCP_RR test:

netperf -t TCP_RR -H foo -- -b N   # N > 1

foo=localhost

b	patched		orig
2	105874.83	105143.71
3	114208.53	114023.07
4	120493.99	120851.27
5	128087.48	128573.33
10	151328.48	151056.00

Probably, the test is done wrong. But I see no difference.

to increase as a result.   Pipelined HTTP would be like that, some NFS 
over TCP stuff too, maybe X traffic,

X will be excited about better latency.

What's about protocols not interested in latency, they will be a little
happier, if transactions are processed asynchronously.

But actually, it is not about increasing/decreasing number of ACKs.
It is about killing that pain in ass which we used to have because
we pretended to be too smart.

Alexey