I'm catching up with email in reverse order, to avoid repeating
points, so sorry if I miss something...

>Even if the NetBSD host doesn't have PMTU turned on, the current
>scheme  would still be a win if the host on the other side could do
>PMTU.  Using the old scheme, we would only advertise a 576 byte
>MSS, and the other side would be limited to sending segments of the
>same size as ours.  The ACK-every-second-packet fix makes
>it possible for us to get maximal receive performance when
>we are communicating with a PMTU-equipped host.

>I certainly think that this is arguable,

No, i think this mauch is pretty straightforward.  I don't think I
disagree, given teh qualifications about PMTU.

The basic disagreement is about how prevalent PMTU is, and about
whether we should break existing behaviour in order to better
accomodate PMTU.

Negotiated-MSSS is known, relied-upon, existing behaviour. Go ask
Vernon Schryver.  People have been told to rely on this behaviour for
for years before PMTU was heard of.

where we disagree is here:

>My enthusiasm for the new in_maxmtu MSS scheme (aside from
>the fact that it comes straight from RFC 1191) comes from
>my perception of the reality of multihomed hosts, asymmetric links,
>and mobility.  I think that it is very likely that a connection
>could be issued from the Ethernet interface of Host A,
>and the return path could come back over the FDDI interface.

In my litle corner of the world, with Metricom radios, and old
FDDI-attached hosts which are not going to do PMTU anytime soon, the
perception is very different.  Maybe things are different at NAS.
I have no way to know that ;)

But in_maxmtu *does* break existing behaviour and *does* break
existing setups.  But what I am saying, and will continue to say, is
that breaking existing practice for the benefit of something that is
not pervasively deployed, and *may not even be under the control of
the NetBSD user*,  is just not on.

NetBSD'S in_maxmtu has to be configurable. From my end, that much is
non-negotiable.  And I still think the default should be off if the
default for pmtu is configured off (as it is now).

I hope where i'm coming from is clearer, now.