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.

Hi Jason,

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=
 of=20
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=
er=20
to be a ballancing over unuequal MTU/MRU. For this kind of ballancing PMTUD=
=20
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=
RU=20
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=
me=20
largest interface MTU - 40 ? I guess not, because during a TCP flow one can=
=20
create an interface (or probably just activate that interface) with larger=
=20
MTU than the above and that new link may be in the reverse path. But RFC793=
=20
doesn't allow mss re-announcement in middle of a flow so basicly we must re=
ly=20
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=
nce=20
maxiumum MSS and rely entirely on RFC1191. Anyway, I think this is the case=
=20
of gigabit interfaces that use jumbo frames and should announce MSS 9k in t=
he=20
actual schema.
	- 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 =
at=20
connection startup. In case we are accepting a connection and if we have a=
=20
route MTU for that host/prefix we must check if the received syn is coming=
=20
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 =
we=20
are the initiators of the connection send MSS =3D ROUTE_MTU-40 directly.

=2D-=20
Cheers,
Mihai