Subject: Re: Limiting the advertised MSS, again.
To: NetBSD Networking Technical Discussion List <tech-net@NetBSD.ORG>
From: Greg A. Woods <email@example.com>
Date: 12/07/2001 00:01:15
[ 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
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
# on the other hand since we know what we are doing at this end
# it maybe does make sense to use Path-MTU-discovery.
# This seems like a very good idea regardless....
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; <firstname.lastname@example.org>; <email@example.com>; <firstname.lastname@example.org>
Planix, Inc. <email@example.com>; VE3TCP; Secrets of the Weird <firstname.lastname@example.org>