In message <200002281800.NAA02240@lawyers.lerc.nasa.gov>Mark Allman writes
>Sorry to be piling onto this thread very late.  I am drowning in
>email and it has taken a cross-country flight to clean all this old
>stuff out...

No problem, I just had to go back through my archives to find
out which position I'd taken in the first place. :-)

>My hit is that rfc1323 should probably be off by default, but for a
>different reason than others have stated.  My argument is that
>typically we don't need rfc1323 support because typically we don't
>send ~128KB of stuff over a TCP connection, so there is no way we
>can build cwnd anywhere near 64KB (i.e., max without rfc1323
>support).  So, why burn the bits on timestamps?  (Especially on low
>bandwidth links).  A couple other points...

I continue to believe that as we get fatter and fatter pipes,
it'll be more and more important to have stuff like this turned
on.  OTOH, when folks like Jamshid Madavi and Mark Allman are
against something, I start to wonder what I'm overlooking...
 
>  * I would be in favor of raising the default socket buffer sizes
>    to 64KB by default.  In other words, let the network dictate
>    performance rather than some arbitrary limit imposed by the host
>    (And, more generally, adding autotuned socket buffers, ala the
>    SIGCOMM98 paper from PSC). 
>
>  * And, while I am potificating...  NetBSD needs a SACK-based
>    loss recovery algorithm (he says hoping someone else has cycles
>    to implement that!).

This seems like it'd be a good thing.  I had the SACK portion of
this working last October at the IETF, but managed to drop the
laptop, destroying my disk and loosing about a months worth of 
work on it...

Pointers to the PSC work are available at:

	http://www.psc.edu/networking/tcp.html

Kevin
kml@logictier.com