TCP/IP protocol stack

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.

The 4 Layers of the TCP/IP stack - protocol suite

PDU - protocol data unit names

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.

PDU - protocol data unit names

Protocol data units for the Internet protocol suite are:

The Maximum Transmission Unit (MTU)

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.

MTU for Ethernet II frame

Typical MTUs are:

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.

What is MSS - Maximum Segment Size

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.

TCP MSS

The Maximum Segment Size (MSS) and RFC

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:

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

The Maximum Segment Size (MSS)

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:

1. If no MSS is advertised the maximum allowed segment size is 536.
2. A host is only allowed to send a larger segment if had received an larger MSS options in the actual session.
3. Normally the MSS is send inside the SYN segments
4. 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.
5. 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.

The other protocols

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.

Sources

• crnetpackets.com
• wikipedia.org - TCP MSS
• wikipedia.org - PDU