On Mon, 6 Apr 1998 15:55:16 -0700 (PDT) 
 Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:

 > However, the problem of poorly-timed ACKs causing huge bursts
 > (just as with stretched ACKs) still remains in NetBSD.  

Tell me how I can reproduce this on my machine.  The exact command,
please.

FWIW, I have seen NO problems with "poorly timed ACKs", when using
the loopback interface or otherwise.

If there's really a problem, I want to fix it.  But you have to tell
me how I can reproduce it.  If you won't, or can't, and I am not able
to independently observe the problem, what conclusion am I supposed to
come to?

 > I am, BTW, getting really tired of this ``if I dont' see it in front
 > of my nose, it doesn't exist'' attitude to performance problems in
 > NetBSD.  The problems are there, they're real, they've already been
 > shown to various NetBSD developers in the past.  Including, as it
 > happens, Jaosn Thorpe.

Quite frankly, I'm getting tired of this "I've shown it to you, now
fix it" attitude from *you*.  As far as I'm concerned, you haven't
shown me much of anything if you don't describe *exactly* how to
reproduce this problem (given that I have not observed this on my
own test systems, and in fact, my time-sequence plots of NetBSD's
TCP doing a "ttcp" over the loopback interface, over moderately-loaded
Ethernets, and over long-hauls with some packet loss look textbook
perfect!)

 > I was *trying* to ask Jason what was going on with this, since I'd
 > discussed this specific problem of bogus MTU calculations with him
 > before.  If Jason forgot about that, then that's his bad.

Actually, I happen to disagree with your analysis of the "problem".

When a host advertises an MSS to the peer, the recommended value is:

	Largest MTU of any physical interface with an IP address
	assigned to it minus the size of the TCP + IP headers.

This recommendation is specifically designed to leave the loopback
interface out of the computation!  The rationale is something like this:

Really, a host could just always advertise 64k as its rx MSS.  However,
this is not recommended since:

	(1) It is unlikely that any real interface will have an MTU
	    (or MRU) large enough to deal with 64k (and in the case
	    where you do have such an interface, you automatically
	    advertise the correct value given the recommended formula
	    above), and

	(2) there are hosts on the Internet that get extremely confused
	    when they see large MSS advertisements (in particular,
	    they interpret anything larger than (32k - 1) as a negative
	    number).

Your suggestion amounts to always advertising a (32k - sizeof(struct tcpip))
as our rx MSS, which is basically NOT RECOMMENDED in the relevant RFC (sorry,
I'm not going to quote a RFC/Section right now, because I am actually trying
to resurrect the CVS server, which had a disk failure while I was in
Los Angeles attending the aforementioned IETF meeting).

If you want to do something special-case for research purposes, then by
all means do so (i.e. HACK YOUR KERNEL!  This is why we hand out source,
after all..)

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