[e2e] Question on MTU
david.borman at windriver.com
Thu Apr 21 15:13:22 PDT 2005
The "effective send MSS" takes into account options, but the MSS value
put into the TCP MSS option should not. In section 220.127.116.11 of RFC
The MSS value to be sent in an MSS option must be less than
or equal to:
MMS_R - 20
where MMS_R is the maximum size for a transport-layer
message that can be received (and reassembled). TCP obtains
MMS_R and MMS_S from the IP layer; see the generic call
GET_MAXSIZES in Section 3.4.
And in section 3.3.2:
There MUST be a mechanism by which the transport layer can
learn MMS_R, the maximum message size that can be received and
reassembled in an IP datagram (see GET_MAXSIZES calls in
Section 3.4). If EMTU_R is not indefinite, then the value of
MMS_R is given by:
MMS_R = EMTU_R - 20
since 20 is the minimum size of an IP header.
The receiver can't reliably predict what IP or TCP options the sender
is going to put into the packets, so it doesn't include them in the MSS
option. The sender then does take those options into account when
calculating the "effective send MSS", because it knows exactly what
options are going into the packet.
On Apr 21, 2005, at 3:59 PM, Joe Touch wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> See RFC1122 Section 18.104.22.168 on calculating the MSS advertised in the
> MSS option. Condensed from that section:
> The eff.snd.MSS takes options at both IP and TCP layers
> into account - this is the size of the largest segment
> actually sent.
> The MSS value sent in the MSS option must be <= MSS_R - 20,
> where MSS_R is from GET_MAXSIZES in sec 3.4.
> Sec 3.4 refers to 3.3.3, which defines:
> MMS_S = EMTU_S - <IP header size>
> and EMTU_S must be less than or equal to the MTU of the
> interface corresponding to the source address of the datagram.
> Note that <IP header size> in this equation will be 20, unless
> the IP reserves space to insert IP options for its own
> in addition to any options inserted by the transport layer.
> I.e., IP options ARE accounted for in the advertised MSS.
> As you noted, intermediate headers (shims like IPsec and HIP) are
> to handle because they aren't treated as options, and may not
> necessarily be known to either IP or TCP. My understanding is that most
> implementations adjust the IP MSS accordingly, so it gets passed up to
> TCP as per secs 3.3.3 and 3.4 of 1122 above.
> David Borman wrote:
>> On Apr 21, 2005, at 11:28 AM, Joe Touch wrote:
>>> MSS usually refers to a transport protocol, e.g., TCP, and denotes
>>> max payload size there too. It is also relative to the network (IPv4,
>>> IPv6) protocol _and_ link layer used.
>>> And just as link layer overhead sizes vary, so do network layer
>>> sizes (minimums of 20 for IPv4, 40 for IPv6 - larger if options are
>>> included, e.g., 48 for IPv6 with jumbogram option).
>> But the advertised MSS in the TCP MSS option should not be adjusted to
>> reflect any options or intermediary headers, just the fixed IP and TCP
>> header sizes; 40 bytes for IPv4/TCP, and 60 bytes for IPv6/TCP. When
>> the sender generates the packet, he is responsible for reducing the
>> data to allow room for any additional options or headers.
>> -David Borman
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
More information about the end2end-interest