This is the first in a series of three blogs which hopefully, will nail down once and forever, what MTU and MSS are and why do they even exist, in the first place.

Preliminaries …

Occasionally, I will refer to the OSI layers, particularly, Layers 2 and above. By convention, when I do so, please consider the layers as below:

  • Layer 1 & 2: Network Link
  • Layer 3: IP (Internetwork)
  • Layer 4: TCP (Transport)
  • Layer 5 – 7: Application

Traditionally, the following units were used for each layer:

  • L1 – bits
  • L2 – frames
  • L3 – packets
  • L4 – segments
  • L5 – L7 – data

Nowadays, this terminology is somehow diluted whereby “packets” is the term used more generically and depending on context, the term of “frames” is used when referring to Layer2.

As packets travel through the network …

  1. Encapsulation occurs top-down the layers -> headers get added at each layer; packets get bigger
  2. Decapsulation occurs down-top the layers -> headers are removed at each layer; packets get smaller
  3. The payload is the information to which headers are added – so the IP payload will include the TCP header as well as anything else that TCP previously encapsulated


But how large should the Layer2 payload be? This maximum limit will depend on the Layer2 protocol being used as well as the actual media type.

Though the main point here is that, there are limits and, when limits are exceeded, fragmentation occurs – this is, assuming the protocol supports it. But there are cases when the protocol does not support fragmentation and in such cases, the packet is going to be dropped.

IP is an example of a Layer3 protocol which does support fragmentation; unlike Ethernet, a Layer2 protocol, which does not. Yet, there are Layer2 protocol which support fragmentation, such as X.25 or ATM (splits Ethernet frames in 48 bytes payload).

Note: Say data needs to flow between two Ethernet switches. If the two work with different maximums (say only one of them allows for jumbo frames) and, since Ethernet doesn’t use fragmentation, there is a chance that some frames would be dropped!!

Furthermore, fragmentation causes extra CPU and memory overhead at both ends – first the sender has to fragment; secondly, the receiver has to reassemble the packets.

Though if the packets are too small, the extra overhead (large number of packets to be processed, headers on each packet, connection maintenance, etc”) may not compensate for the lack of fragmentation.


We cannot eliminate fragmentation; though we should find an optimum compromise. We will do so by setting specific limits to our payloads – IP MTU and TCP MSS provide such limits.

Thank you,
View Rafael A Couto Cabral's profile on LinkedIn

Comments are closed.