> I've attached a tcpdump snippet where the .2 second spans are obvious.

Content-Description: 1.txt
> 12:36:17.991144 10.0.1.186.514 > 10.0.1.1.704: P 193:195(2) ack 419 win 32850 <nop,nop,timestamp 143 143> (DF)
> 12:36:17.991395 10.0.1.1.704 > 10.0.1.186.514: P 419:422(3) ack 195 win 32850 <nop,nop,timestamp 143 143> (DF)
> 12:36:17.991500 10.0.1.186.514 > 10.0.1.1.704: P 195:197(2) ack 422 win 32850 <nop,nop,timestamp 143 143> (DF)
> 12:36:18.183591 10.0.1.1.704 > 10.0.1.186.514: . ack 197 win 32850 <nop,nop,timestamp 143 143> (DF)
> 12:36:18.183644 10.0.1.186.514 > 10.0.1.1.704: P 197:199(2) ack 422 win 32850 <nop,nop,timestamp 144 143> (DF)
> 12:36:18.183874 10.0.1.1.704 > 10.0.1.186.514: P 422:424(2) ack 199 win 32850 <nop,nop,timestamp 143 144> (DF)
> 12:36:18.380045 10.0.1.186.514 > 10.0.1.1.704: . ack 424 win 32850 <nop,nop,timestamp 144 143> (DF)

If I read that trace correctly it looks as though the sending end is
doing a 'wait for more data' is spite of the 'push' flag being set.

Surely this is wrong?
IIRC about the only thing the push flag mans is 'send this now and
don't wait for any more data because there won't be any'.

The 'ack on push' feature' is an M$ abomination - used because it
retransmits from the users buffer and many applications won't send
any more data until their buffer is released.

Of course the 'send me an ack for this packet' is a very useful protocol
feature - but is completly orthoginal to the tcp push flag. (You normally
push data if you have no more to send and are expecting an application
level ack next, you request an ack if you have no more space for holding
unacked data or if you suspect the link is very lossy.)

	David

-- 
David Laight: david@l8s.co.uk