Subject: Re: MSS doesn't honour route MTU
To: Jason Thorpe <firstname.lastname@example.org>
From: Mihai CHELARU <email@example.com>
Date: 06/16/2006 11:31:45
On Friday 16 June 2006 01:59, Jason Thorpe wrote:
> Which is correct. The MSS is independent of the MTU. The MSS is a
> value advertised to the peer that says "this is the maximum segment
> size I am willing to receive".
> Even net.inet.tcp.mss_ifmtu is a brain-dead hack that should have
> never seen the light of day.
I strongly disagree with you on this one. Why doesn't NetBSD announce MSS=20
65535 all the time if MSS is independent of the MTU ?
On Friday 16 June 2006 06:09, Jason Thorpe wrote:
> The point is, it's up to the sender. =A0MSS is defined as the maximum =A0
> segment size I'm willing to receive, period. =A0What if you have a TCP =A0
> connection that floats from one interface to another over time?
In this case it will be better just to stick with the lowest MTU-40 instead=
relying on PMTUD because I don't expect a flow to go over one link 10=20
minutes(RFC1191) and then 10 minutes over the other and then back, but rath=
to be a ballancing over unuequal MTU/MRU. For this kind of ballancing PMTUD=
will not do a thing except a probably a packet resend every pmtud timeout.
There is somehow one posibility that a connection will start over a lower M=
path and after a while (let's presume that the primary link goes up) the=20
connection will go through a higher MRU path. In this case it's better to=20
announce a higher MSS from the first time. But again, is it correct to assu=
largest interface MTU - 40 ? I guess not, because during a TCP flow one can=
create an interface (or probably just activate that interface) with larger=
MTU than the above and that new link may be in the reverse path. But RFC793=
doesn't allow mss re-announcement in middle of a flow so basicly we must re=
on the conditions at the start of the connection. So, my arguments are:
- assume MRU =3D MTU else drop the entire MSS =3D MTU - 40 thing and annou=
maxiumum MSS and rely entirely on RFC1191. Anyway, I think this is the case=
of gigabit interfaces that use jumbo frames and should announce MSS 9k in t=
- use the conditions at startup. Keep in mind that hosts can't usually=20
control the path of a (TCP) flow so it must rely entirely on what it knows =
connection startup. In case we are accepting a connection and if we have a=
route MTU for that host/prefix we must check if the received syn is coming=
from the next hop as that route and in this case announce ROUTE_MTU - 40.=20
Otherwise use the interface MTU-40 on which we received the SYN packet. If =
are the initiators of the connection send MSS =3D ROUTE_MTU-40 directly.