Re: 2.6.10 TCP troubles -- suggested patch

[Nivedita Singhvi <niv@us.ibm.com>]

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