[e2e] Question on MTU

[David Borman]

Joe,

The "effective send MSS" takes into account options, but the MSS value 
put into the TCP MSS option should not.  In section 4.2.2.6 of RFC 
1122:

             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.

			-David Borman


On Apr 21, 2005, at 3:59 PM, Joe Touch wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> See RFC1122 Section 4.2.2.6 on calculating the MSS advertised in the 
> TCP
> 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 
> network
>          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 
> purposes
>          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 
> harder
> 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.
>
> Joe
>
> 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 
>>> the
>>> 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 
>>> overhead
>>> 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 
>> TCP
>> 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
>
> iD8DBQFCaBRKE5f5cImnZrsRAuVHAJ9eaIBHKXMZxhzcMgldOvFVphYRIACffqGL
> qWTwK4RCNc/QWYLQxi4tYOU=
> =SChT
> -----END PGP SIGNATURE-----