Re: 6.2 mtu now limits size of incomming packet

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

--

"They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin)

"The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson)



_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: 6.2 mtu now limits size of incomming packet
    ... think more about asymmetry in maximum transmission unit is this one: ... advertised MSS, which presumably avoids an extra PMTU round trip if jumbograms are enabled on the receiving endpoint. ... 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? ... There are also things to consider such as if a GigE card is connected to a GigE device and the card supports jumbo frames should the MRU be set to the max jumbo receive size for the card? ...
    (freebsd-net)
  • Re: 6.2 mtu now limits size of incomming packet
    ... about asymmetry in maximum transmission unit is this one: ... In syncache_responddo not reply with a MSS that is larger than what ... win in avoiding a PMTU round-trip worth disallowing asymmetric MSS at the TCP ... I don't see any reason for TCP to cap the MSS at the received MSS. ...
    (freebsd-net)
  • Re: Changing TCP MSS under LINUX
    ... That will cause TCP to send smaller segments to avoid fragmentation. ... The DF bit is not set in the header of the IP datagram carrying the ... If the fancy feature in the network cannot do either of these things ... I know following MSS manipulation mechanisms under LINUX: ...
    (comp.os.linux.networking)
  • FW: Small TCP packets == very large overhead == DoS?
    ... read/write packets are generally 8k in size. ... when I worked out you could fragment packets inside the TCP header ... they would normally send me (with an MSS of 1436). ... just as there is no "minimum MTU" size for IP. ...
    (FreeBSD-Security)
  • Userland PPP MSS miscalculation?
    ... FreeBSD calculates the TCP MSS value of a new TCP connection by ... TCP options; the number of bytes that TCP options consume are effectively ... By removing the -12 from the MAXMSS calculation and recompiling ppp, ...
    (freebsd-questions)