On Tue, 07 Apr 1998 15:48:48 -0700 
 Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:

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

It's known, (bogusly, IMO) relied-upon, existing behavior in BSD-derived
TCPs.  Not all TCPs implemeted it this way, you know.  And not all
BSD-derived TCPs do it that way anymore (NetBSD isn't the only one; Dave
Borman and I had an e-mail conversation about this issue just after the
Munich IETF, and he indicated that he did something very similar in BSD/OS).

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

I'm sorry, but I am not about to bend over backwards to accomodate
ancient hosts running ancient TCPs.  In all of the cases you've stated,
the intervening router(s) would be able to fragment (which is allowed,
altough not optimial, in IPv4), and your packets would get through.  If
you're really upset about fragmentation, then set "subnetsarelocal" to 0.
Sure, this isn't optimal, but the hosts in question probably have 4.2BSD
or 4.3BSD TCPs, the latter of which was especially ill-behaved in many
respects (esp. congestion control in the latter case).

>From where I'm sitting, you or I or anyone else can come up with arbitrarily
screwey network setups all day long.  The point is that at some point you
have to move forward.  That is what we are trying to do given current
understanding of how things work and how we want them to work, and current
feelings among the engineers (that's a key word choice, BTW) who are doing
the work.

 > 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 could accept a knob that would enable the old, broken MSS advertisement
behavior (I think BSD/OS has such a knob), but I would not accept enabling
the old, broken MSS behavior by default.  Note, the BSD/OS knob does not
enable "negotiation", but rather changes the code to advertise an MSS to
the peer computed as follows:

	if (in_localaddr(address of peer))
		mss = recvif->if_mtu - sizeof(struct tcpiphdr);
	else
		mss = tcp_mssdflt;

Jason R. Thorpe                                       thorpej@nas.nasa.gov
NASA Ames Research Center                            Home: +1 408 866 1912
NAS: M/S 258-5                                       Work: +1 650 604 0935
Moffett Field, CA 94035                             Pager: +1 415 428 6939