First off, some of these issues were being worked on with the OpenBSD 
NFSv4.  Perhaps that's close to ready for integration in NetBSD.  I'm 
told things went well at the bakeoff in June.

David Laight wrote:
> 
> If a system sends a large TCP message it will go out as back to back
> ethernet frames.  

To a max of 4 segments, assuming following RFC recommendations.

> The receiving systems tcp stack will (probably)
> generate TCP ACKs for every other frame.  None of these can be transmitted
> because the media is busy, 

But that's only 2 Acks queued for the 4 segments.

> so the MAC starts doing longer and longer
> timeouts.  Then the response will also get queued.  

But the response should piggyback on the last Ack (2, 4, 6, etc., 
whenever that may be).

> Eventually the MAC
> will find the LAN idle and send out a back to back stream of ACKs
> followed by the response.  The original system now has to process
> all the ACK packets before getting to the response itself.
> 
Well, 2 of them in the case of 4 segments.  For more than that, the 
Acks have already been processed by the Ack clocking in slow start.
-- 
William Allen Simpson
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32