Date: Sat, 14 Jul 2007 21:37:10 -0500 From: Mike Karels <karels@karels.net> To: Robert Watson <rwatson@FreeBSD.org> Cc: Stephen.Clark@seclark.us, Sten Daniel Soersdal <netslists@gmail.com>, Julian Elischer <julian@elischer.org>, Bill Moran <wmoran@collaborativefusion.com>, freebsd-net@FreeBSD.org Subject: Re: 6.2 mtu now limits size of incomming packet Message-ID: <200707150237.l6F2bAgZ011098@redrock.karels.net> In-Reply-To: Your message of Sun, 15 Jul 2007 00:46:27 %2B0100. <20070715003156.B94899@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> A related change that should probably be discussed if we want to think more > about asymmetry in maximum transmission unit is this one: > ---------------------------- > revision 1.98 > date: 2006/06/26 17:54:53; author: andre; state: Exp; lines: +2 -0 > In syncache_respond() do not reply with a MSS that is larger than what > the peer announced to us but make it at least tcp_minmss in size. > Sponsored by: TCP/IP Optimization Fundraise 2005 > ---------------------------- > In this change, we cap the advertised MSS in SYN/ACK to the received > advertised MSS, which presumably avoids an extra PMTU round trip if jumbograms > are enabled on the receiving endpoint. However, it also prevents use of > larger packet sizes if asymmetric MTU is supported. I think I suggested after > this was committed that we at least add an administrative twiddle to > enable/disable this mode of operation, but don't see one in there currently. > Does the Secure Computing scenario use TCP in this way, and is the potential > win in avoiding a PMTU round-trip worth disallowing asymmetric MSS at the TCP > layer? In our case, TCP isn't aware of the MRU, and bases its MSS on the MTU values. However, I don't see any reason for TCP to cap the MSS at the received MSS. If the other end doesn't want to receive more than 1024 bytes, that's no reason to refuse to accept more. Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200707150237.l6F2bAgZ011098>