--aqWxf8ydqYKP8htK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, Jun 16, 2006 at 12:29:44AM +0100, Rui Paulo wrote:
> > Which is correct.  The MSS is independent of the MTU.  The MSS is a =20
> > value advertised to the peer that says "this is the maximum segment =20
> > size I am willing to receive".
>=20
> Ok, so how does it recieve something that's not under the values of
> the MTU ?

perhaps it doesn't mind doing so, lots of NFS setups use 8k UDP frames
that get fragmented at the IP level, and there can be circumstances
where the same is fine for TCP. =20

Many wireless networks implement TCP-like recovery and in-order
delivery, and multi-frame transmit, at the MAC layer; the things that
argue against ip-fragmenting TCP segments on normal networks are less
applicable there, and I can best exploit these features if TCP will
allow them to be used, avoiding some duplicated header and processing
overhead. Alternately, one might want to disable those MAC-layer
features and expose the real characteristics to a smarter TCP with
SACK and other modern features, to gain higher aggregate throughput
over multiple streams.

> And, what should the route -mtu option do, after all ?

route mtu and interface mtu are distinct, many interfaces with
different mtu may be in the path.  I would (without thinking about it
terribly closely) expect that route -mtu would set the initial value
that would otherwise be discovered by PMTUD. =20

TCP can then use both the remote endpoint's advertised MSS and its own
relevant PMTU (among other variables) when deciding what size to send.

The way I see it, clamping the MSS I advertise for the receiver based
on what I think I can send in the other direction is just wrong.  It
may be helpful to work around broken PMTU discovery on the path in
that direction, but it's entirely possible that the PMTU is quite
different in each direction. Again, wireless networks may provide an
example where I want assymmetric transmit behaviour between stations
and APs.

If we need something explicitly tunable in the routing table for TCP
to do assume-symmetric-path MSS clamping as a receiver, so be it - but
it should be a different parameter.

--
Dan.

--aqWxf8ydqYKP8htK
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (NetBSD)

iD8DBQFEkgwyEAVxvV4N66cRAkDHAKDKVfB/XR6pwid2Dhtj9ksifQfHlwCgsC6F
hWAVzSG3zKp97FswBon9noo=
=FWie
-----END PGP SIGNATURE-----

--aqWxf8ydqYKP8htK--