Er, how is this compliant with 2581 (yes, I know, it's only a SHOULD, not a
MUST)  - an ACK should be generated for at least every second full-sized
segment received? Don't see that happening. In many cases it's receiving
quite a few more packets. It should not be waiting for the delayed ack timer
to go off, surely?

Certainly it would make for an interesting disuscion.  Indeed it is a
SHOULD which leaves-open the door to compliance of other ACK policies.  Those 
might result in an ACK for more than two segments, or even an ACK for fewer than 
two segments, and there are folks in either camp/faction/sect/pick your favorite 
term.

I would say that it is still compliant with 2581.  The must there is that no 
matter what, an ACK must be generated within 500 milliseconds.

I suspect that had a full cwnd's worth of data been sent there would have been 
no lengthy delay in ACKs even with fewer than ACK-every-other.  I suspect that 
had TSO been disabled the full cwnd would have been sent and these delayed ACKs 
would not have happened and the transfer speed would have been happiness and joy.

FWIW, as the industry has added features such as CKO (ChecKsum Offload), 
copy-avoidance, and now TSO, the pie chart of time spent has been shifting more 
and more to ACK processing.  If we go back far enough, the writeups talk about 
how delayed ACK to increase ACK piggybacking was added in the first place - 
specifically (IIRC) for the purpose of minimizing ACK overhead.

rick jones

BTW, I'd be happy to trim emails that are already on netdev to avoid message 
duplications, is netdev a "closed" list?