On Mon, 6 Apr 1998 02:24:18 -0700 (PDT) 
 Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:

 > 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....

`Stretch ACK violation' was failure to generate an ACK for every two segments
received.  There was actually some confusion about this within the TCPIMPL
WG.  Some thought this was meant to be "two maximum size segments", others
thought this was meant to be "two segments, regardless of size".  I decided
to implement the latter, since the receiver cannot know the path MTU, because
the receiver may be using a different path to get to the peer, or may not be
sending segments large enough to discover the MTU limits of the path.  I fixed
that in our stack at the DC IETF.  While I was at it, I also shaved a few %
off tcp_fasttimo() in the call profile (esp. if system has a large number of
TCP connections or listeners).

The `ACK immediately on reception of PSH' was recently fixed by me, while
at the LA IETF.  You ought to read source-changes from time to time.  This
one was actually somewhat controversial within the NetBSD camp, since `ACK
immediately on PSH' was originally designed to solve a performance problem
that can occur on high delay*bandwidth links.  However, after discussing it
with people who deal with those sorts of links on a daily basis, we came to
the agreement that the condition in question doens't really happen that often,
and the change doens't really help it that much, in any case.  Hence, I backed
out the `ACK immediately on PSH' change that was made to our TCP a couple of
years ago.

 > 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?

MTU/MSS calculation is NOT "hosed".  I've personally spoken with several
TCPIMPL and TCPSAT WG members _at length_ about NetBSD's MSS/MTU behavior,
and I can't find anyone who sees a problem with how NetBSD does things.

We (actually Kevin) did recently fix a couple of slight problems with it,
which are documented in the known problems draft, which also happen to exist
on other systems.  They have to do with TCP option and IP option lengths
not being considered in "segment size to transmit" computation.  The IP
option bug was not previously documented, actually, but will be in the
next version of the known problems draft.

If you can point to a SPECIFIC problem, by all means do, but don't just
assert that there's a problem without really describing it.

(And, can you please get your terminology right?  The syn_cache_*() funtions
are not "SYN-flood compressed state".  The compressed state engine is used
for all embryonic TCP connetions, not just when we believe we are under
a SYN-flood attack; this is the main difference between us and BSD/OS in
this regard.)

In any case, as far as I know, NetBSD-current does not have any of the
problems documented in any current version of the known-problems draft,
and I intend to have -current's TCP pulled up onto the netbsd-1-3 branch
for inclusion in 1.3.2.  (Participation in TCPIMPL is the whole reason I
go to the IETF, so I'm quite familiar with the problems in the document.)

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939