I realise that this has been discussed before, but there is one fine point
that I'm not grasping.  Perhaps someone can straighten things out for me.

I was trying to download files from one of my remote NetBSD servers, and
was getting <10 KB/sec from it, while a Linux box sitting next to it,
connected to the same switch, etc. could easily push files at over 100
KB/sec.

My network setup looks like this:

workstation --- firewall --- Linksys DSL modem (PPPoE) --- Internet --- server

Running tcpdump, the problem was fairly obvious: my server was sending out
512-byte packets.  Adjusting mssdflt to 1024 greatly improved the
performance.  Also, leaving mssdflt alone and turning on mtudisc worked
even better (as it sent at the maximum possible size).

Apparently, the MSS that either the server or this workstation advertises
is mangled by the DSL modem (it becomes 1452 instead of 1460) to reflect
the PPPoE overhead.  (Of course, the host still thinks that it advertised
a 1460 MSS.)

I understand why changing either of those sysctl variables works.  What I
don't understand is why the NetBSD server doesn't set its packet size
according to the MSS advertised by my workstation (1452).  Or, why it
doesn't send packets of size 1460 and let some router out there (I guess
it would be my ISP in this case) fragment them.

BTW, what is the "correct fix" for this situation?  Turning on mtudisc
would be fine, except that I can't trust all sites to do it properly
(which is really too bad, because it's neat).  Increasing the mssdflt
would be okay, except that it seems silly to be tweaking this value,
because the workstation _is_ advertising a MSS.

Also, setting mssdflt to something ridiculous (like 16384) causes the
packet size to become 1452.  I don't understand that either...shouldn't
the packet size be huge and then just get fragmented?

-- 
Tyler Mitchell

"Wherever you go, there you are."
      -- Douglas Adams