>ftp://ftp.isi.edu/internet-drafts/draft-ietf-tcpimpl-prob-03.txt


>It would probably good for someone who is intimate with the NetBSD TCP to
>go over it with the the "common problems" document along side...

They've been looked at since preprints of Vern's SIGCOMM 97 papers
came out.  Netbsd does fine on most of the earlier bugs.

But we lose bigtime on the stretch ACK.  Even -current can trivially
be tickled into generating ACKs once every window.  The easiest
way isto fire up ttcp over loopback or between two machines....

Yup, I just did both Ether and loopback, and this bug is still
there. I have a ttcp running over Ethernet from machine A to machine
B, with a tcpdump on the reciever (B). The receiver didn't start
sending back any ACKs till the whole damn window of 5 Kbytes got
there.  And the receiver is running -current.


I've stared at the delayed-ack code just this past weekend and futzing
with the sender-side code in tcp_input().  It _looks_ like it's doing
the right thing with delayed acks, but it isn't.  I've been griping
about this on and off for the last 18 months, since it leads to loss
of self-clocking. which in turn can do truly horrible things to
performance.

BTW, looking at the loopback trace, our MTU/MSS calculation is *still*
hosed, and has been since approximately when the SYN-flood compressed
state went in.  I had forgotten about that since; was it beleived ot
have been fixed already, or not?