[ On Saturday, September 2, 2000 at 16:19:54 (+1100), Robert Elz wrote: ]
> Subject: Re: fragmentation by NetBSD routers vs. reassembly on other systems.... 
>
>     Date:        Sat,  2 Sep 2000 01:14:33 -0400 (EDT)
>     From:        woods@weird.com (Greg A. Woods)
>     Message-ID:  <20000902051433.E73A85@proven.weird.com>
> 
>   | In any case lowering mssdflt, even well below half the lowest MTU on any
>   | path to any server I was having problems connecting to did not have the
>   | desired effect.
> 
> That's what jhawk was trying to tell you.  You clearly aren't
> understanding what the variable alters (it can raise the MSS, it can't
> lower it).

That's not exactly what the code says, or does.  Certainly if it causes
512-byte (data) packets to some types of hosts when it is set to 512,
and 1460-byte packets to the same hosts when it is set to 1460, then
obviously it can raise *and* lower the MSS, at least in any situation
where it can have some effect.  The proof was clearly visible in the
evidence collected by actual experimentation.  At that time I didn't try
lowering the MSS below 512 though -- the idea then was to improve
performance, not degrade it.

Perhaps what you meant to say is that mssdflt cannot lower the MSS
below the size advertised by the remote system.

>   The warning in the man page is there for a reason, and
> it isn't just "you will cause fragmentation".

So, what's your interpretation?

> This sysctl var is a truly weird one - with very limited utility, which
> almost no-one should ever be fooling with.

On the contrary!!!!  As I said, increasing it to 1460 saved my bacon by
increasing throughput for cable modem users up to be on par with an NT
server!  Turning on mtudisc would no doubt provide equal improvement,
but of course only where Path-MTU-discovery can be known to work 100%.
For those servers I couldn't give a hoot if I cause extra fragmentation
for external Internet users (i.e. on somone elses router! ;-), but it
was absolutely critical that performance for local users be increased to
the point where they couldn't clearly discern the difference between
slow but apparently local servers and obviously remote servers that by
hop count should have been slower than the local ones.

Indeed it wasn't so long ago that I suggested somewhere that perhaps it
was time to change the default setting of mssdflt from 512 to at least
1024, if not 1400.  I don't recall receiving any dissenting opiions at
the time....

I note that RFC 1122 says only "SHOULD use EMTU_S <= 576 whenever the
destination address is not on a connected network", and of course that
advice was written in 1989 when much of the Internet probably ran across
WAN links with smaller MTUs.  These days, as has been said repeatedly in
several forums, by several people, very little of the Internet has a
Path-MTU of less than 1500 bytes, *except* for dial-up end-point systems
which are capable of advertising a lower MSS if they care to avoid
fragmentation (i.e. Path-MTU is probably only very very rarely lower
than the lesser of the MTUs of the end-point systems).  Even with PPPoE
there's nothing really changing, except in the rare cases where someone
such as myself routes a small network over such a connection (but then I
was doing that with dial-up PPP before too).  First or last hop
fragmentation is not (usually) anywhere near as harmful as it is when it
has to happen on some core router.

Furthermore, as I showed above, with the increasing speeds commonly
available between non-local servers and clients (i.e. many WAN links are
faster now than old-fashioned LANs were!) the old default MSS of 512 for
non-local hosts greately impairs throughput.  Leaving it at that value
when there's little likelyhood that the Path-MTU will ever be less than
the interface MTU is definitely not helping anyone win any benchmarks if
they don't want to use Path-MTU-discovery!

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>