[ On Saturday, September 2, 2000 at 00:12:46 (-0400), John Hawkinson wrote: ]
> Subject: Re: fragmentation by NetBSD routers vs. reassembly on other systems....
>
> | The result was that my little NetBSD/i386-1.4V running the
> | GIF-over-cable-modem tunnel was then forced to fragment my packets.  I
> | knew this would happen so I set "net.inet.tcp.mssdflt = 1200" in an
> | effort to convince my system so send properly sized packets..
> 
> As the manpage says:
> 
> 		     Do
>                      not change this value unless you really know what you are
>                      doing.
> 
> The advertised MSS is the greater of the max interface mtu less 40 bytes,
> or the mssdflt. So setting it is useless if you wish to lower the
> advertised MSS (as you do).

Well, I do know what I am doing, or at least in so much as I've been
able to follow the current code and compare the difference with what I
read in Stevens, et al., and given my understanding of TCP.

I suspect the warning in the manual page is merely there to prevent
people from causing unnecessary fragmentation.  In any case this doesn't
have anything whatsoever to do with the apparent inability of a remote
server to receive and correctly reassemble the fragmented packets I was
ultimately sending to it.

Note that the choice between using the current interface MTU to
calculate MSS, or the value of mssdflt, is based on whether or not the
host is on the local network, or at least one hop away, and in this case
all of my errors have been with hosts at least one hop away.

BTW, the current default of 512 is absolutely absurd on any server that
hands out bulk data (eg. HTTP, FTP, etc.) to clients that are on
high-speed, low-latency, routed, connections and which do not advertise
an MSS upon connect.  Without changing this value on NetBSD, and without
using mtudisc, throughput sucks like dead pigs through clogged storm
drains.  It's absolutely necessary to either risk the problems with
broken Path-MTU-discovery or to increase the mssdflt to at least 1400.
I had to answer some serious allegations about NetBSD's poor performance
from the point of view of cable modem customers of the ISP I'm
supporting until I figured out this little tewak.  With more and people
running stupid broken home firewalls there's no way we could risk
turning on mtudisc.

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.  Of course in most of these cases the remote server
did reply with an MSS of 1460, thus preventing my adjustment of mssdflt
from having any effect:

22:01:17.939204 204.92.254.15.65040 > xxx.xxx.xxx.xxx.25: S [tcp sum ok] 1329520945:1329520945(0) win 16384 <mss 1460,nop,wscale 0,nop,nop,timestamp 5712348 0> (ttl 64, id 24632)
22:01:18.778107 xxx.xxx.xxx.xxx.25 > 204.92.254.15.65040: S [tcp sum ok] 3555059635:3555059635(0) ack 1329520946 win 32120 <mss 1460,nop,nop,timestamp 66128365 5712348,nop,wscale 0> (ttl 45, id 19007)
22:01:18.778228 204.92.254.15.65040 > xxx.xxx.xxx.xxx.25: . [tcp sum ok] ack 1 win 17520 <nop,nop,timestamp 5712350 66128365> (ttl 64, id 24652)

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