Stephen Clark wrote:
Mike Karels wrote:
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
So was any decision reached on this issue - will FreeBSD changed to
accept a packet on an
interface that is larger than the mtu on that interface?
Steve
There are also things to consider such as if a GigE card is connected to
a GigE device (switch/card etc) and the card supports jumbo frames
should the MRU be set to the max jumbo receive size for the card? This
could cause confusion when people plug jumbo capable devices in with
hardware limitations making the MRU lower than other devices on the network.
Just some thoughts.
Tom
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "[EMAIL PROTECTED]"