[e2e] Question on MTU

[Joe Touch]

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