On Fri, 7 Dec 2001 kml@selresearch.net wrote:

> In message <Pine.NEB.4.33.0112062151470.3863-100000@Apenheul.BigScaryChildren.n
> et>Rick Byers writes:
> >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).
> [...]
> >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?
>
> I thought that your earlier patch looked fine.  I kinda liked the name
> that jhawk suggested, maxmss, but that doesn't really seem important.
> Having a way to lower the advertised MSS doesn't seem like the end
> of the world.  It certainly doesn't violate the end-to-end principle
> the way that MSS-clamping does.  (And even that is not the end of the
> world, I guess, given NAT and all the rest of the evil out there.)
>
> I don't have the problem, so it is easy for me to get on my high horse.

Thanks :).  I changed the name only because I wanted to make it explicit
that it was affecting only the ADVERTISED MSS, and not the maximum sending
segment size.  There are too many "something_mss" variables in the kernel,
so the meaning of "MSS" has gotten blurred.  It doesn't help that MSS
doesn't really mean "maximum segment size" but "maximum IP datagram size
minus 40".

Oh well, thanks for your input :)
	Rick