First of all, we should remember us, at the four layers of the TCP/IP protocol Suite. The next drawing will show us, where the different protocols of TCP/IP stack reside compared to the OSI model. Also it will show us which protocols are used at the different layers.
In telecommunications, a protocol data unit - PDU is a single unit of information transmitted among peer entities of a computer network. It is composed of protocol-specific control information and user data. In the layered architectures of communication protocol stacks, each layer implements protocols tailored to the specific type or mode of data exchange.
For example, the Transmission Control Protocol - TCP implements a connection-oriented transfer mode, and the PDU of this protocol is called a segment, while the User Datagram Protocol - UDP uses datagrams as protocol data units for connectionless communication. A layer lower in the Internet protocol suite, at the Internet layer, the PDU is called a packet, irrespective of its payload type.
Protocol data units for the Internet protocol suite are:
|Ethernet (Link Layer)||Frame|
|Transport Layer TCP||Segment|
|Transport Layer UDP||UDP Datagram|
In computer networking, the maximum transmission unit (MTU) is the size of the largest protocol data unit (PDU) that can be communicated in a single network layer transaction. The MTU relates to, but is not identical to the maximum frame size that can be transported on the data link layer, e.g., Ethernet frame. Larger MTU is associated with reduced overhead. Smaller MTU values can reduce network delay.
Typical MTUs are:
|WLAN with A-MSDU support||7951|
|Token Ring (IEEE 802.5)||4464|
The MTU limits the amount of data at the link layer and is dependent from the individual link and we have some interesting facts around it.
- It is more or less a physical limit
- It is specified for each link separately
- MTU reduction can occur elsewhere in the communication path
- The sender and receiver doesn't know anything about the limitation in the path
- As a mitigation Path MTU Discovery has been developed
But we come back to MTU later again. Now we go on to the TCP Header and its Maximum Segment Size MSS option.
The IP datagram containing a TCP segment may be self-contained within a single packet, or it may be reconstructed from several fragmented pieces; either way, the MSS limit applies to the total amount of data contained in the final, reconstructed TCP segment.
To avoid fragmentation in the IP layer, a host must specify the maximum segment size as equal to the largest IP datagram that the host can handle minus the IP and TCP header sizes. Therefore, IPv4 hosts are required to be able to handle an MSS of 536 octets (= 576 - 20 - 20) and IPv6 hosts are required to be able to handle an MSS of 1220 octets (= 1280 - 40 - 20).
Small MSS values will reduce or eliminate IP fragmentation but will result in higher overhead. Each direction of data flow can use a different MSS. For most computer users, the MSS option is established by the operating system.
Mainly there are three RFCs which handle the behaviour and the definition of the Maximum Segment Size(MSS) :
- RFC 793, Transmission Control Protocol, September 1981
- RFC 879, TCP Maximum Segment Size, November 1983
- RFC 1122, Requirements for Internet Hosts - Communication Layers, October 1989
- RFC 9293 - Transmission Control Protocol (TCP), August 2022
So what do they tell us about the MSS?
- First the RFC 793 tells us that the Maximum Segment Size (MSS) is an option of the TCP header and it must be sent only when the SYN bit is set.
- Furthermore, the RFC 793 had defined the obsolete definition that any segment size is allowed if the MSS is not advertised, but it is updated by RFC 879 and all later ones.
- The RFC 879 defines that every host must be able to receive IP datagrams with the size of 576 octets.
- The RFC 879 also defines the default TCP Maximum Segment Size (MSS) with 536. And that a host is only allowed to send a larger segments, if he has received a MSS option. does not
The RFC1122 defines the following interesting behaviours:
22.214.171.124 TCP Options: TCP MUST be able to receive a TCP option in any segment. …
The RFC 9293 in Maximum Segment Size Option section define this:
3.7.1. Maximum Segment Size Option TCP endpoints MUST implement both sending and receiving the MSS Option (MUST-14). TCP implementations SHOULD send an MSS Option in every SYN segment when its receive MSS differs from the default 536 for IPv4 or 1220 for IPv6 (SHLD-5), and MAY send it always (MAY-3). If an MSS Option is not received at connection setup, TCP implementations MUST assume a default send MSS of 536 (576 - 40) for IPv4 or 1220 (1280 - 60) for IPv6 (MUST-15).
Summarized the RFC1122 and RFC9293 defines the following:
- TCP Options are allowed in every TCP segment
- It recommends the sending of MSS option within the SYN packet. Otherwise the default MSS of 536 octets is in use
- The MSS option MAY be send within every TCP segment
- The effective packet size is defined by the smaller value of received (MSS – 40) or own MTU
At last we have the informational RFC6691 TCP Options and Maximum Segment Size, 2012. This RFC makes suggestions how to handle the MSS if the sum of the IP and the TCP headers is greater than 40 octets. The RFC6691 suggests that the sender has to alter the received MSS transparently by himself at each time he wants to send a ip datagram, because he is the only one who knows how much longer the headers are.
So with all this said, we can reliable say how the MSS works, now:
- If no MSS is advertised the maximum allowed segment size is 536.
- A host is only allowed to send a larger segment if had received an larger MSS options in the actual session.
- Normally the MSS is send inside the SYN segments
- The maximum IP datagram size which a host is allowed to send is defined either by the received MSS limit or the own MTU limit. The smaller value of this both is the limit which counts.
- The maximum MSS is calculated at the TCP layer by removing 40 Bytes from the allowed MTU size. This could cause problems if IPsec or TCP options like Timestamps are in use
And in the most cases, it is effective for both sides. For one side of the session the MSS is the countable limit and for the other side the MTU is the countable limit, so that both sides use the same effective size of IP datagram.
But what about the other protocols, which don't have the TCP MSS option? Let's have a look at the RFC792 INTERNET PROTOCOL, 1981: In the definition of the Total Length field of the IP header the following is defined:
Total Length: 16 bits Total Length is the length of the datagram, measured in octets, including internet header and data. This field allows the length of a datagram to be up to 65,535 octets. Such long datagrams are impractical for most hosts and networks. All hosts must be prepared to accept datagrams of up to 576 octets (whether they arrive whole or in fragments). It is recommended that hosts only send datagrams larger than 576 octets if they have assurance that the destination is prepared to accept the larger datagrams.
So we can see:
- Every host of the TCP/IP protocol suite MUST at least support the IP datagram size (MTU) of 576
- The maximum size of an IP datagram is 65535 due to the length of the field.
- A host should only send larger datagrams if he has assurance that the destination supports it
If we look at the different protocols especially aplications that use UDP we can see that most of them do not generate larger IP datagrams then 576 octecs. And if they do, they will mostly allow the fragmentation of the IP datagrams. So that we don't need to be surprised any longer, if we see UDP datagrams with the Fragmentation Allowed Bit set wihin their IP header.