[e2e] Question on MTU

[Joe Touch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi, Dave,

David Borman wrote:
> 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.

The MSS you send to the other side is the side you can receive, which
has nothing to do with your options - TCP or IP

As you correctly note, this is related to MSS_R - 20 (sorry - I used the
MSS_S value).

> 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.

Agreed. The primary issue to me was that the options - both IP and TCP -
are taken into account in computing the MSS TCP uses, whether obtained
by looking at the local interface or learned by the PMTUD mechanisms.

FWIW, the shims sometimes cobble things by setting the interface MTU
down by the amount they add, effectively 'adding' space for it as a
result. (sometimes; sometimes it's not so easy to point to which
interface will be used, at which point I don't know if they decrement
all interfaces or try to do anything more context-dependent)

Joe

> On Apr 21, 2005, at 3:59 PM, Joe Touch wrote:
> 
> 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

iD8DBQFCaDo2E5f5cImnZrsRAv95AKCMo1Tn9unqDs30y0+fLbqFmWlq7wCgj6TU
kyYj0EwJ72DRqmH2Y5/90gU=
=wIau
-----END PGP SIGNATURE-----