Rick Jones wrote:

000010 10.107.96.7.32801 > 10.107.96.230.139: . 11692:13140(1448) ack 
822 win 1460 <nop,nop,timestamp 534449 1709240658> NBT Packet (DF)
000004 10.107.96.7.32801 > 10.107.96.230.139: . 13140:14588(1448) ack 
822 win 1460 <nop,nop,timestamp 534449 1709240658> NBT Packet (DF)
000002 10.107.96.7.32801 > 10.107.96.230.139: P 14588:16036(1448) ack 
822 win 1460 <nop,nop,timestamp 534449 1709240658> NBT Packet (DF)
000022 10.107.96.7.32801 > 10.107.96.230.139: . 16036:17484(1448) ack 
822 win 1460 <nop,nop,timestamp 534449 1709240658> NBT Packet (DF)
000004 10.107.96.7.32801 > 10.107.96.230.139: P 17484:18192(708) ack 822 
win 1460 <nop,nop,timestamp 534449 1709240658> NBT Packet (DF)
000994 10.107.96.230.139 > 10.107.96.7.32801: . ack 18192 win 65535 
<nop,nop,timestamp 1709240658 534449> (DF)
0

And then other cases where the ACK seems to take a rather long time to 
arrive, seems to correlate a bit with slowly increasing numbers of 
segments before the ACK is sent, and something along the lines of a 200 
millisecond delayed ACK timer.

In some cases at least if the sender does not completely fill cwnd the 
ACKs will be delayed.  And IIRC under 2.6.10 with TSO enabled, the 
sender does not always fill cwnd.

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?

thanks,
Nivedita