[ On Thursday, December 6, 2001 at 22:02:11 (-0500), Rick Byers wrote: ]
> Subject: Limiting the advertised MSS, again.
>
> Someone mentioned that lowering the MTU on a route should cause the
> TCP MSS to get lowered correspondingly.  I thought it was working, but I
> must have been drunk or something, because the per-route MTU doesn't seem
> to affect the advertised MSS at all (which I should have known since I've
> was staring at the tcp_mss_to_advertise code).

Hmmm.... isn't Path-MTU Discovery implemented in NetBSD by simply
adding a host route with a per-route MTU?  Path-MTU-discovery certainly
seemed to work the last time I needed it....   Hmmm.... or does that
only need to lower the MSS of outgoing packets, leaving the peer to deal
with it on its own...

> So, other than the patch I recently posted, there doesn't appear to be
> any way to convince NetBSD to lower the advertised MSS without lowering
> the interface MTU.  I consider being able to lower the advertised MSS a
> handy feature, especially considering all the broken networks.  Its
> conceivable that someone might want to use NetBSD behind a reduced-mtu
> gateway which they have no control over, and which doesn't implement TCP
> MSS clamping.  In that scenario, the only way to cope with blackholed
> sites is to convince NetBSD to lower the MSS it advertises.

If you're behind such a reduced-MTU gateway then it might be simpler to
just the MTU on your interface and be done with it.  Of course if you've
got a lot of local traffic to consider then you might try to find a way
to subnet and multi-home your machine so that you only have to reduce
the MTU on the interface connected to the gateway.

> Anyway, I know some people belive we shouldn't provide an option to cope
> with broken networks, but I believe the situation is already desperate
> enough that there is nothing to be gained by holding this feature back.
> Does anyone else think there should be a sysctl for lowering the MSS, or
> is there some better way?  Perhaps a per-route MRU or something to that
> effect?

Is there any reason why the setting of a per-route MTU cannot be made to
work?  If per-route MTUs don't affect the MSS does that mean the current
Path-MTU discovery code assumes the peer is also doing the same?

You could also just try setting net.inet.tcp.mssdflt to some smaller
value.  Back when I was using a GIF tunnel for my default route I was
experimenting with the following settings in /etc/sysctl.conf:

	# the GIF tunnel needs some bytes for the GIF header...
	#
	# somehow or another the GIF still has to fragments packets
	# sometimes, even when mssdflt is set way low
	#
	net.inet.tcp.mssdflt=1024

	# on the other hand since we know what we are doing at this end
	# it maybe does make sense to use Path-MTU-discovery.
	# 
	net.inet.ip.mtudisc=1

	# This seems like a very good idea regardless....
	#
	net.inet.tcp.mss_ifmtu=1

As you can see from my comments I wasn't 100% successful with
controlling packet sizes, and at the time I was having trouble resolving
differences between what I read in Stevens' books and the NetBSD code.

Maybe all we need is a 'net.inet.tcp.mss_rtmtu' flag.... ;-)

-- 
								Greg A. Woods

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