Hubbry Logo
Maximum transmission unitMaximum transmission unitMain
Open search
Maximum transmission unit
Community hub
Maximum transmission unit
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Maximum transmission unit
Maximum transmission unit
Maximum transmission unit
View on Wikipedia
from Wikipedia

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.[1]: 25  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. In many cases, MTU is dependent on underlying network capabilities and must be adjusted manually or automatically so as to not exceed these capabilities. MTU parameters may appear in association with a communications interface or standard. Some systems may decide MTU at connect time, e.g. using Path MTU Discovery.

Applicability

[edit]

MTUs apply to communications protocols and network layers. The MTU is specified in terms of bytes or octets of the largest PDU that the layer can pass onwards. MTU parameters usually appear in association with a communications interface (NIC, serial port, etc.). Standards (Ethernet, for example) can fix the size of an MTU; or systems (such as point-to-point serial links) may decide MTU at connect time.

Underlying data link and physical layers usually add overhead to the network layer data to be transported, so for a given maximum frame size of a medium, one needs to subtract the amount of overhead to calculate that medium's MTU. For example, with Ethernet, the maximum frame size is 1518 bytes, 18 bytes of which are overhead (header and frame check sequence), resulting in an MTU of 1500 bytes.

Tradeoffs

[edit]

A larger MTU brings greater efficiency because each network packet carries more user data while protocol overheads, such as headers or underlying per-packet delays, remain fixed; the resulting higher efficiency means an improvement in bulk protocol throughput. A larger MTU also requires processing of fewer packets for the same amount of data. In some systems, per-packet-processing can be a critical performance limitation.

However, this gain is not without a downside. Large packets occupy a link for more time than a smaller packet, causing greater delays to subsequent packets, and increasing network delay and delay variation. For example, a 1500-byte packet, the largest allowed by Ethernet at the network layer, ties up a 14.4k modem for about one second.

Large packets are also problematic in the presence of communications errors. If no forward error correction is used, corruption of a single bit in a packet requires that the entire packet be retransmitted, which can be costly. At a given bit error rate, larger packets are more susceptible to corruption. Their greater payload makes retransmissions of larger packets take longer. Despite the negative effects on retransmission duration, large packets can still have a net positive effect on end-to-end TCP performance.[2]

Internet protocol

[edit]

The Internet protocol suite was designed to work over many different networking technologies, each of which may use packets of different sizes. While a host will know the MTU of its own interface and possibly that of its peers (from initial handshakes), it will not initially know the lowest MTU in a chain of links to other peers. Another potential problem is that higher-level protocols may create packets larger than even the local link supports.

IPv4 allows fragmentation which divides the datagram into pieces, each small enough to accommodate a specified MTU limitation. This fragmentation process takes place at the internet layer. The fragmented packets are marked so that the IP layer of the destination host knows it should reassemble the packets into the original datagram.

All fragments of a packet must arrive for the packet to be considered received. If the network drops any fragment, the entire packet is lost.

When the number of packets that must be fragmented or the number of fragments is great, fragmentation can cause unreasonable or unnecessary overhead. For example, various tunneling situations may exceed the MTU by very little as they add just a header's worth of data. The addition is small, but each packet now has to be sent in two fragments, the second of which carries very little payload. The same amount of payload is being moved, but every intermediate router has to forward twice as many packets.

The Internet Protocol requires that hosts must be able to process IP datagrams of at least 576 bytes (for IPv4) or 1280 bytes (for IPv6). However, this does not preclude link layers with an MTU smaller than this minimum MTU from conveying IP data. For example, according to IPv6's specification, if a particular link layer cannot deliver an IP datagram of 1280 bytes in a single frame, then the link layer must provide its own fragmentation and reassembly mechanism, separate from the IP fragmentation mechanism, to ensure that a 1280-byte IP datagram can be delivered, intact, to the IP layer.

MTUs for common media

[edit]

In the context of Internet Protocol, MTU refers to the maximum size of an IP packet that can be transmitted without fragmentation over a given medium. The size of an IP packet includes IP headers but excludes headers from the link layer. In the case of an Ethernet frame this adds a protocol overhead of 18 bytes, or 22 bytes with an IEEE 802.1Q tag for VLAN tagging or class of service.

The MTU should not be confused with the minimum datagram size (in one piece or in fragments) that all hosts must be prepared to accept. This is 576 bytes for IPv4[1]: 24  and 1280 bytes for IPv6.[3]: 25 

Media for IP transport Maximum transmission unit (bytes) Notes
Internet IPv4 path MTU At least 68,[1]: 24  max of 64 KiB[1]: 12  Systems may use Path MTU Discovery[4] to find the actual path MTU. Routing from larger MTU to smaller MTU causes IP fragmentation.
Internet IPv6 path MTU At least 1280,[3] max of 64 KiB, but optional jumbograms go up to 4 GiB[5] Systems should use Path MTU Discovery[3] to find the actual path MTU, unless the minimum MTU (1280 bytes) is not exceeded.
Jumbograms are packets with a Jumbo Payload option to allow transmission of payloads between 65,536 and 4,294,967,295 octets in length.
X.25 Minimal 576 (sending) or 1600 (receiving)[6]
Ethernet v2 1500[7] Nearly all IP over Ethernet implementations use the Ethernet II frame format.
Ethernet with LLC and SNAP 1492[8]
Ethernet jumbo frames 1501–9202[9] or more[10] The limit varies by vendor. For correct interoperation, frames should be no larger than the maximum frame size supported by any device on the network segment.[11]
PPPoE v2 1492[12] Ethernet II MTU (1500) less PPPoE header (8); extensions exist
DS-Lite over PPPoE 1452 Ethernet II MTU (1500) less PPPoE header (8) and IPv6 header (40)
PPPoE jumbo frames 1493–9190 or more[13] Ethernet Jumbo Frame MTU (1501–9198) less PPPoE header (8)
IEEE 802.11 Wi-Fi (WLAN) 2304[14] The maximum MSDU size is 2304 before encryption. WEP will add 8 bytes, WPA-TKIP 20 bytes, and WPA2-CCMP 16 bytes. See also Frame aggregation mechanisms in 802.11n.
Token Ring (802.5) 4464
FDDI 4352[4]

Ethernet maximum frame size

[edit]

The IP MTU and Ethernet maximum frame size are configured separately. In Ethernet switch configuration, MTU may refer to Ethernet maximum frame size. In Ethernet-based routers, MTU normally refers to the IP MTU. If jumbo frames are allowed in a network, the IP MTU should also be adjusted upwards to take advantage of this.

Since the IP packet is carried by an Ethernet frame, the Ethernet frame has to be larger than the IP packet. With the normal untagged Ethernet frame overhead of 18 bytes and the 1500-byte payload, the Ethernet maximum frame size is 1518 bytes. If a 1500-byte IP packet is to be carried over a tagged Ethernet connection, the Ethernet frame maximum size needs to be 1522 bytes due to the larger size of an 802.1Q tagged frame. 802.3ac increases the standard Ethernet maximum frame size to accommodate this.

Path MTU Discovery

[edit]
Main article: Path MTU Discovery

The Internet Protocol defines the path MTU of an Internet transmission path as the smallest MTU supported by any of the hops on the path between a source and destination. Put another way, the path MTU is the largest packet size that can traverse this path without suffering fragmentation.

Path MTU Discovery is a technique for determining the path MTU between two IP hosts, defined for both IPv4[4] and IPv6[15]. It works by sending packets with the DF (don't fragment) option in the IP header set. Any device along the path whose MTU is smaller than the packet will drop such packets and send back an ICMP Destination Unreachable (Datagram Too Big) message which indicates its MTU. This information allows the source host to reduce its assumed path MTU appropriately. The process repeats until the MTU becomes small enough to traverse the entire path without fragmentation.

Standard Ethernet supports an MTU of 1500 bytes and Ethernet implementation supporting jumbo frames, allow for an MTU up to 9000 bytes. However, border protocols like PPPoE will reduce this. Path MTU Discovery exposes the difference between the MTU seen by Ethernet end-nodes and the Path MTU.

Unfortunately, increasing numbers of networks drop ICMP traffic (for example, to prevent denial-of-service attacks), which prevents path MTU discovery from working. Packetization Layer Path MTU Discovery[16][17] is a Path MTU Discovery technique which responds more robustly to ICMP filtering. In an IP network, the path from the source address to the destination address may change in response to various events (load-balancing, congestion, outages, etc.) and this could result in the path MTU changing (sometimes repeatedly) during a transmission, which may introduce further packet drops before the host finds a new reliable MTU.

A failure of Path MTU Discovery carries the possible result of making some sites behind badly configured firewalls unreachable. A connection with mismatched MTU may work for low-volume data but fail as soon as a host sends a large block of data. For example, with Internet Relay Chat a connecting client might see the initial messages up to and including the initial ping (sent by the server as an anti-spoofing measure), but get no response after that. This is because the large set of welcome messages sent at that point are packets that exceed the path MTU. One can possibly work around this, depending on which part of the network one controls; for example one can change the MSS (maximum segment size) in the initial packet that sets up the TCP connection at one's firewall.

In other contexts

[edit]

MTU is sometimes used to describe the maximum PDU sizes in communication layers other than the network layer.

The transmission of a packet on a physical network segment that is larger than the segment's MTU is known as jabber. This is almost always caused by faulty devices.[23] Network switches and some repeater hubs have a built-in capability to detect when a device is jabbering.[24][25]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Maximum transmission unit

View on Grokipedia
from Grokipedia
The Maximum Transmission Unit (MTU) is the largest size, measured in bytes, of a (such as an IP ) that can be transmitted over a specific network interface or link without requiring fragmentation into smaller units. This limit is defined at the and varies depending on the underlying network technology, ensuring efficient data transmission by balancing packet size against overhead and potential bottlenecks. For instance, exceeding the MTU on a given link prompts routers to fragment packets, which introduces processing overhead, increases the risk of , and can degrade network performance. The concept of MTU originated in the early development of internet protocols, with the (IP) specification in 1981 explicitly addressing fragmentation to handle varying MTU sizes across interconnected networks. In standard Ethernet networks, governed by , the default MTU is 1500 bytes, excluding headers like the 14-byte header and 4-byte CRC, which allows for a total frame size of up to 1518 bytes. This value became a for most local area networks (LANs) due to hardware constraints in early Ethernet implementations, such as buffer sizes in network interface cards. Other common MTU sizes include 576 bytes as the minimum reassembly buffer required for IPv4 hosts (though the absolute minimum link MTU is 68 bytes) and larger "jumbo frames" up to 9000 bytes or more in high-performance environments like data centers to reduce overhead from frequent packet processing. A critical aspect of MTU management is , a standardized that enables end hosts to dynamically determine the smallest MTU along an entire network path, avoiding fragmentation by adjusting packet sizes accordingly. Introduced in RFC 1191 in 1990, PMTUD works by sending packets with the "Don't Fragment" flag set and using ICMP "Fragmentation Needed" messages from routers to probe and refine the effective path MTU. This mechanism is essential for protocols like TCP, where the (MSS) is often clamped to the path MTU minus protocol headers (typically 1460 bytes for a 1500-byte MTU with 20-byte IP and 20-byte TCP headers), optimizing throughput and reliability. Misconfigurations, such as blocked ICMP messages, can lead to "black hole" connectivity issues where large packets are silently dropped, highlighting the ongoing importance of proper MTU tuning in modern networks including VPNs, , and cloud environments.

Fundamentals

Definition and Scope

The maximum transmission unit (MTU) is defined as the maximum sized that can be transmitted through a given network without fragmentation. This represents the largest (PDU) that a network interface or path can handle in a single transaction at the relevant protocol layer. MTU applies across various layers of the network stack, including the where it governs frame sizes on , and the network layer where it primarily constrains packet transmission for protocols like IP. At the network layer, a distinction exists between the link MTU, which is the hardware-imposed maximum IP packet size (including the but excluding link-layer framing) that can be sent over a single link in one piece, and the path MTU, which is the minimum link MTU along an end-to-end path between source and destination. MTU is typically measured in bytes (or equivalently, octets, which are eight-bit units), encompassing the full PDU size unless specified otherwise. In contexts like IP, this includes protocol headers, though related concepts such as the TCP maximum segment size (MSS) focus on excluding transport and network headers to optimize transmission. For instance, just as postal systems impose envelope size limits to ensure efficient handling without splitting contents, network MTUs set boundaries to prevent fragmentation and maintain performance.

Historical Development

The concept of the maximum transmission unit (MTU) originated in early packet-switched networks during the 1970s, particularly with the , where link MTUs varied by interface, such as 1006 bytes on ARPANET interfaces to accommodate packet fragmentation across heterogeneous networks. This approach influenced the design of protocols to handle varying packet sizes without universal standardization at the time. The formalization of MTU in internet protocols came with RFC 791 in 1981, which defined the (IPv4) and specified that every internet destination must be able to accept datagrams of at least 576 bytes, establishing this as the minimum reassembly buffer size for hosts to support fragmentation and reassembly across diverse networks. Concurrently, the Ethernet standard, initially published as the DIX Ethernet Version 1 specification in 1980 by , , and , set a standard MTU of 1500 bytes for local area networks, balancing error rates and transmission efficiency on 10 Mbps shared media; this was later ratified in in 1983, becoming the foundational MTU for most LAN implementations. Key advancements in the 1990s addressed path variability: RFC 1191 in 1990 introduced (PMTUD), a mechanism for endpoints to dynamically determine the smallest MTU along an path, reducing unnecessary fragmentation by allowing senders to adjust packet sizes based on ICMP feedback. The transition to , outlined in RFC 2460 (1998) and updated in RFC 8200 (2017), raised the minimum link MTU to 1280 bytes to simplify deployment on modern links while prohibiting fragmentation in transit routers, shifting more responsibility to endpoints. Influential standards bodies shaped broader adoption: continued to evolve Ethernet MTU definitions, maintaining 1500 bytes as the baseline while enabling extensions, and recommendations, such as those in the G-series for transmission systems (e.g., G.7041/Y.1303), incorporated MTU considerations into telecommunications frameworks for optical transport, supporting Ethernet sizes like 1600 octets. In the post-2000 era, support for jumbo frames emerged to enhance efficiency in high-speed environments, with Ethernet implementations allowing MTUs up to 9000 bytes or more in data centers and storage networks, driven by needs for reduced overhead in and beyond. By the 2020s, 5G networks, governed by 3GPP specifications such as TS 38.323, supported maximum sizes up to 9000 bytes in the layer, enabling larger MTUs in backhaul and core configurations to optimize throughput for diverse applications like ultra-reliable low-latency communications.

Applicability Across Layers

At the , the maximum transmission unit (MTU) defines the largest frame size that can be reliably transmitted over a physical medium, encompassing the entire including headers for addressing (such as MAC addresses), control fields, , and trailer elements like the (FCS) for integrity verification. This frame-level limit ensures that data is formatted appropriately for the underlying hardware and medium, preventing transmission failures due to oversized units. For instance, in Ethernet networks, the standard maximum frame size is 1518 bytes, which includes 14 bytes for the header and 4 bytes for the FCS, thereby constraining the effective to 1500 bytes. The determination of MTU at this layer is heavily influenced by the physical characteristics of the , including signal delays, cable lengths, and susceptibility to interference or , which can necessitate adjustments to maintain reliable delivery. In environments with high or poor , such as links, larger frames increase the transmission duration and thus the exposure to errors, often leading to the adoption of smaller MTUs to reduce retransmission overhead and improve overall reliability. Specific media impose distinct limits: networks under IEEE 802.5 support a maximum frame size of approximately 4500 bytes on 4 Mbit/s links and up to 18,000 bytes on 16 Mbit/s links, reflecting speed-dependent buffering and timing constraints. In contrast, IEEE 802.11 networks typically limit the maximum (MSDU) to 2304 bytes, accounting for the challenges of radio signal variability and interference in shared environments. Hardware components, particularly network interface cards (NICs), enforce these MTU limits through configured buffer capacities and port specifications, dropping or rejecting frames that exceed the supported size to avoid processing errors. This enforcement at the directly bounds the effective MTU available to higher layers, as the network layer must construct packets that fit within the link frame payload after accounting for data link overhead, ensuring seamless encapsulation without mandatory fragmentation at the boundary.

Network Layer Interactions

At the network layer, the maximum transmission unit (MTU) defines the largest size of an IP datagram that can be transmitted over a link without fragmentation, ensuring compatibility across diverse network infrastructures. For IPv4, the minimum link MTU is 68 octets, allowing routers and hosts to forward datagrams of this size without further fragmentation, as specified in the protocol's foundational design. In contrast, mandates a higher minimum link MTU of 1280 octets for every link, eliminating reliance on fragmentation at intermediate nodes and promoting end-to-end packet . This distinction reflects IPv6's architectural shift toward larger, fixed-size packets to accommodate modern network demands while simplifying routing processes. Routers handle MTU constraints during by comparing the size of an incoming IP against the MTU of the outgoing interface. If the exceeds the outgoing MTU and the Don't Fragment (DF) bit is clear, the router fragments the into smaller pieces that fit within the limit, adhering to IPv4 fragmentation rules that require minimizing the number of resulting fragments. However, if the DF bit is set, the router drops the and generates an ICMP "Destination Unreachable" message with code 4 (Fragmentation Needed and DF Set), including the next-hop MTU to signal the issue upstream. This mechanism, rooted in core IP specifications, enables adaptive transmission but introduces overhead in processing and reassembly at the destination. In heterogeneous networks, where links support varying MTUs—such as IPv4 datagrams traversing Ethernet segments with a 1500-octet MTU alongside PPP links often limited to 1492 octets due to encapsulation—routers must navigate path capacities. These disparities can necessitate frequent fragmentation or packet drops, complicating end-to-end delivery and increasing latency in mixed environments like those combining wired and dial-up connections. Tunneling protocols exacerbate these challenges by reducing effective MTUs through added headers, potentially leading to undetected mismatches if signaling fails. To mitigate black holes—scenarios where oversized packets are silently discarded without feedback—routers rely on ICMP messages to notify senders of MTU mismatches, allowing adjustments without full path discovery. When a router drops a DF-set packet due to an insufficient outgoing MTU, the ICMP "Fragmentation Needed" response conveys the limiting MTU value, enabling the source to retransmit smaller datagrams. Blocking or loss of these ICMP messages, however, creates persistent black holes, where connections stall as senders fail to adapt, a problem well-documented in TCP implementations over IP paths.

Performance Tradeoffs

Efficiency and Overhead

The efficiency of network transmission is significantly influenced by the MTU size, as larger MTUs generally improve throughput by reducing the relative proportion of header overhead to data. For instance, in protocols like TCP/IP, a combined header of 40 bytes (20 bytes for the IPv4 header and 20 bytes for the TCP header) represents approximately 2.7% of a 1500-byte MTU, allowing nearly 97.3% of the packet to carry useful data, whereas the same header constitutes 20% of a 200-byte MTU, severely limiting effective bandwidth utilization. This reduction in overhead ratio enables higher overall throughput, particularly in high-bandwidth environments, by minimizing the frequency of header transmissions per unit of data. Overhead can be quantified using the efficiency formula: efficiency = (payload size / total packet size) × 100%, where payload size is the MTU minus the protocol headers. For IPv4 alone, the minimum header is 20 bytes, so for a 1500-byte MTU, the maximum is 1480 bytes, yielding an of about 98.7%; adding a TCP header drops this to 97.3% for the combined 40-byte overhead. In scenarios with small payloads, such as control messages or short bursts, this overhead becomes more pronounced, wasting bandwidth as a larger fraction of each packet is non-data. Beyond bandwidth, costs also factor into MTU efficiency tradeoffs, with larger packets requiring more CPU cycles per packet due to increased handling but fewer overall packets for the same volume, thus reducing total overhead. For example, a 9000-byte replaces six 1500-byte standard frames, eliminating five sets of header and associated interrupts, which can lower CPU utilization in high-throughput scenarios. Conversely, very small MTUs amplify per-packet demands, straining resources on routers and endpoints. Guidelines for optimal MTU sizing emphasize balancing these factors based on network scenarios; for typical local area networks (LANs) using Ethernet, an MTU of 1500 bytes provides efficient performance by minimizing overhead without excessive processing demands on standard hardware. In bandwidth-constrained or latency-sensitive environments, slightly smaller MTUs may be preferred to avoid potential delays from larger packet handling, though 1500 bytes remains the default for most general-purpose LAN efficiency.

Fragmentation Challenges

In IPv4, fragmentation occurs when a router encounters a packet larger than the outgoing link's MTU and the Don't Fragment (DF) bit in the IP header's flags field is set to 0. The flags field consists of three bits: the most significant bit is reserved (set to 0), the DF bit (bit 1) indicates whether fragmentation is prohibited, and the More Fragments (MF) bit (bit 2) signals if additional fragments follow. The 16-bit Identification (IP ID) field assigns a unique value to all fragments of the same original datagram for reassembly, while the 13-bit Fragment Offset field denotes each fragment's position relative to the start of the original data, in units of 8 octets. The MF bit is set to 1 in all but the final fragment. IPv6, by design, prohibits routers from fragmenting packets to simplify forwarding and reduce ; only the source host performs fragmentation if the packet exceeds the path MTU, inserting a Fragment Header into oversized packets. This header includes a 32-bit Identification field (analogous to IPv4's IP ID for matching fragments), an 8-bit M flag (equivalent to MF), and a 13-bit Fragment Offset field, with fragments sized in multiples of 8 octets to fit the path MTU. The first fragment carries the full set of headers up to the upper-layer protocol, while subsequent fragments include only the IPv6 header, routing headers, and payload data. Reassembly of fragments takes place exclusively at the destination host in both IPv4 and , where the receiver must buffer incoming fragments, use the IP ID (or equivalent) and offset values to order them, and reconstruct the original packet once complete. This process burdens the end host's CPU with significant overhead from memory buffering, fragment matching, and validation, particularly under high traffic loads where multiple datagrams require simultaneous reassembly. Incomplete fragment sets pose additional risks; if all pieces do not arrive within a configurable timeout—often 15 seconds for IPv4 upon receipt of the first fragment—the buffered fragments are discarded, triggering upper-layer retransmissions and increasing latency. Fragmentation introduces notable challenges, including security vulnerabilities that enable amplification attacks. The Teardrop attack, for example, sends malformed or overlapping IP fragments with inconsistent offsets to exploit reassembly logic flaws, causing the target system to crash or hang during reconstruction due to improper handling of the bogus packet. suffers from the transmission of multiple smaller packets, which amplifies per-packet header overhead and reduces effective bandwidth; in lossy networks, losing even one fragment invalidates the entire , necessitating full retransmission and compounding delays, especially at high data rates where the 16-bit IP ID field risks collisions and duplicate discards. Mitigation strategies emphasize avoiding fragmentation altogether by preferring end-to-end non-fragmented transmission through accurate path MTU estimation. In IPv4, setting the DF bit to 1 prevents router fragmentation, prompting oversized packets to be dropped with an ICMP "Destination Unreachable—Fragmentation Needed" message to inform the sender of the limiting MTU for adjustment. RFC 8900 underscores IP fragmentation's inherent fragilities—such as reassembly timeouts, ID exhaustion, and attack surfaces—and advocates for its deprecation in favor of robust and conservative MTU configurations to ensure reliable, secure packet delivery. In practical scenarios, such as VPN clients where encapsulation adds overhead, a common mitigation is to manually lower the MTU value in the client's advanced settings, for example to 1400 bytes, to prevent packet fragmentation.

Protocol-Specific Implementations

MTUs in Common Network Media

The Maximum Transmission Unit (MTU) varies across common network media due to differences in physical layer constraints, encapsulation protocols, and performance optimizations. For instance, traditional Ethernet networks standardize at 1500 bytes for the payload, excluding headers, to balance efficiency on shared media. In contrast, technologies like PPP over Ethernet (PPPoE) reduce this to 1492 bytes to accommodate the 8-byte PPPoE header overhead. Asynchronous Transfer Mode (ATM) networks support larger MTUs, with a maximum of 9180 bytes for AAL5 frames, enabling efficient handling of variable-length data over fixed-size cells. Multiprotocol Label Switching (MPLS) allows adjustable MTUs up to 9198 bytes, depending on label stacking and underlying media, to support diverse traffic engineering needs.
Network Media/TechnologyStandard MTU (Bytes)Notes
Ethernet (IEEE 802.3)1500Payload size; excludes 18-byte frame header and 4-byte FCS. Jumbo frames optional up to 9000+ on supported hardware.
PPPoE (over DSL/Ethernet)1492Accounts for 8-byte PPPoE header; common in broadband wired access.
ATM (AAL5)9180Maximum for user data in SAR-PDU; cell size fixed at 53 bytes.
MPLSUp to 9198Adjustable based on label stack (4 bytes per label); often matches underlying MTU.
DSL (e.g., ADSL/VDSL)1492Typically via PPPoE; wired copper-based access with encapsulation limits.
Fiber Optic (10G Ethernet)9000+ (jumbo)Supports larger frames for high-speed backbones; standard 1500 also viable.
Satellite (e.g., DVB-S2)Variable (typically ≤1500)Influenced by high latency and error correction; often lower to mitigate retransmissions.
Wi-Fi (IEEE 802.11)2304 (AMSDU), typically 1500 for IPSupports aggregation for larger payloads; IP often limited to Ethernet standard for compatibility.
Wired media like DSL commonly operate at 1492 bytes due to PPPoE encapsulation in deployments, while fiber optic networks, such as , frequently employ jumbo frames exceeding 9000 bytes to reduce overhead in high-throughput environments. Satellite links exhibit variable MTUs, typically 1500 bytes or less, as higher latency and bit error rates favor smaller packets to minimize retransmission costs. Several factors influence effective MTU sizes in these media. Encapsulation overhead, such as VLAN tags, reduces the usable MTU by 4 bytes per tag, necessitating adjustments in mixed environments. This overhead can accumulate with multiple layers, impacting overall throughput.

Ethernet Frame Size Variations

The standard Ethernet frame, as defined in , supports a maximum transmission unit (MTU) of 1500 bytes for the , resulting in a total frame size of 1518 bytes when including the 14-byte header (destination and source MAC addresses plus length/type field) and 4-byte (FCS). This configuration ensures compatibility across legacy and modern Ethernet implementations while maintaining efficient transmission for typical network traffic. To accommodate VLAN tagging under IEEE 802.1Q, the IEEE 802.3ac amendment extends the maximum frame size to 1522 bytes by adding a 4-byte tag, often referred to as a "baby giant" frame; this allows the same 1500-byte payload MTU without requiring jumbo frame support. Such extensions are common in environments using virtual LANs for segmentation, providing a slight increase in overhead for enhanced network flexibility. Jumbo frames extend the Ethernet payload beyond 1500 bytes, typically up to 9000 bytes in implementations for (10GbE) and higher speeds, reducing overhead in high-throughput scenarios like data centers. RFC 4638, published in 2006, facilitates this by accommodating MTUs greater than 1492 bytes in (PPPoE), enabling jumbo frame support up to approximately 9000 bytes in encapsulated environments. These larger frames are widely adopted in and faster links to minimize CPU processing cycles per byte transferred. In provider bridging networks defined by , the maximum frame size reaches 9216 bytes to support stacked tags (QinQ) and service provider scaling, allowing for efficient tunneling of customer traffic across multiple domains. Frame size variations must also account for control mechanisms, such as IEEE 802.3x pause frames (fixed at 64 bytes minimum) and Control Protocol (LACP) frames under IEEE 802.3ad, which operate within standard sizes but influence buffer configurations in mixed environments. Jumbo frame compatibility relies on manual configuration across all devices, as Ethernet autonegotiation handles only speed and duplex, not MTU; mismatches in mixed and non-jumbo networks lead to frame drops or fragmentation, necessitating uniform end-to-end support to avoid performance degradation.

Path MTU Discovery Mechanisms

(PMTUD) enables a source host to dynamically determine the effective maximum transmission unit (MTU) along the network path to a destination, minimizing fragmentation by adjusting packet sizes accordingly. The core mechanism involves the sender setting the Don't Fragment (DF) bit in IP headers and transmitting packets of increasing size. If a packet exceeds the MTU of any link or router along the path, the encountering device discards it and sends back an ICMP "Destination Unreachable" with Type 3 and Code 4 ("Fragmentation Needed"), including the maximum transmittable unit from that point. The sender then lowers its path MTU estimate to this reported value and may resume probing with incrementally larger packets to refine the estimate upward, typically using a binary search approach for efficiency. In IPv4 networks, PMTUD supplements the legacy capability for routers to fragment packets, though such fragmentation is now deprecated due to overhead and risks. IPv4 implementations often start with a conservative initial path MTU guess of 576 bytes, as this value ensures compatibility across diverse links without prior knowledge. detection addresses scenarios where ICMP feedback is filtered or lost: if probe packets time out without acknowledgment after multiple retransmissions (e.g., three times the retransmission timeout), the sender assumes a path MTU reduction and lowers the estimate by a fixed amount, such as 100 bytes per step, until connectivity resumes. IPv6 mandates stricter adherence to PMTUD, as routers cannot fragment packets; any oversized packet is dropped, and the source must solely rely on discovery to avoid failures. The PMTUD algorithm mirrors IPv4 but uses "Packet Too Big" messages (Type 2) instead of ICMP Type 3 Code 4, with an initial minimum path MTU of 1280 bytes to support the protocol's baseline requirements. Probing proceeds similarly with DF-equivalent semantics via the IPv6 header, and mitigation employs transport-layer timeouts, ensuring end-to-end adaptation without intermediate intervention. A key extension integrates PMTUD with TCP's Maximum Segment Size (MSS) negotiation. During the TCP three-way handshake, the sender clamps the advertised MSS to the current path MTU minus 20 bytes for IPv4 headers (or 40 bytes for IPv6), preventing the receiver from sending segments that would require fragmentation. This adjustment, performed iteratively as the path MTU is refined, ensures seamless operation without altering the core discovery algorithm. To mitigate vulnerabilities in classic —such as reliance on potentially unreliable or spoofable ICMP messages—Packetization Layer Path MTU Discovery (PLPMTUD) introduces resilience through transport-layer feedback. Developed in , PLPMTUD leverages packetization protocols like TCP to infer path MTU via delivery success or loss detection, rather than ICMP alone; probes are sent at exponentially increasing intervals, with the base size starting at a safe value (e.g., 1280 bytes for ) and growing up to a ceiling like 9000 bytes. Upon detecting loss via timeouts or explicit acknowledgments, the algorithm halves the current probe size and restarts, providing robustness against packet drops that mimic black holes. This approach has been widely adopted for its compatibility with transports and reduced dependency on network-layer signals. In practice, when automated PMTUD mechanisms are impaired (such as by filtered ICMP messages leading to black holes) or for performance fine-tuning, manual path MTU determination using diagnostic tools is common. A standard method employs the ping utility with the "don't fragment" flag to identify the largest non-fragmenting packet size. On Windows systems, the command ping -f -l [size] [destination] (e.g., ping -f -l 1472 8.8.8.8) is used iteratively to find the maximum payload size that succeeds without fragmentation; the path MTU is then this size plus 28 bytes (20-byte IPv4 header + 8-byte ICMP header). This technique is particularly useful for connections with encapsulation overhead, such as PPPoE, where the effective MTU is typically 1492 bytes due to the 8-byte PPPoE header overhead from a standard 1500-byte Ethernet MTU. The PPPoE specification requires that the MTU not exceed 1492 bytes. In specific applications, such as online gaming over PPPoE connections (for example, in Valorant), users have reported reduced lag, desync, or inconsistent performance by manually configuring the client interface MTU to the tested maximum non-fragmenting value, commonly 1492 bytes or lower (e.g., 1450–1472 bytes), especially when automatic discovery yields suboptimal results.

WireGuard

WireGuard, a modern virtual private network (VPN) protocol, specifies the MTU in the [Interface] section of its configuration file. The default value in general implementations is 1420 bytes, which accounts for approximately 60 bytes of encapsulation overhead over IPv4 (20-byte IP header + 8-byte UDP header + 32-byte WireGuard header) when operating over a standard 1500-byte Ethernet MTU. For IPv6, the overhead is about 80 bytes due to the 40-byte IP header. An MTU set too high may cause packet fragmentation or drops, while one set too low decreases efficiency by requiring more packets for the same data volume. On certain platforms, such as iOS in the official WireGuard app, the default MTU is 1280 bytes to promote compatibility with varied network conditions. Optimization typically involves tuning the MTU according to path MTU discovery results; in VPN clients, including those using WireGuard, a practical troubleshooting step for MTU issues is to manually lower the MTU value in the client's advanced settings, for example to 1400 bytes, to prevent packet fragmentation caused by encapsulation overhead.

Applications Beyond IP Networking

Storage and SAN Protocols

In storage area networks (SANs), the Maximum Transmission Unit (MTU) is adapted to support high-throughput data transfers for block-level storage operations, where efficiency is critical due to the large volumes of sequential I/O typical in enterprise environments. Fibre Channel, a primary protocol for SANs, employs a standard frame format with a 2112-byte payload capacity, resulting in a total frame size of 2148 bytes including headers. This size balances low latency with sufficient payload for storage commands and data, as defined in Fibre Channel standards to minimize overhead while handling typical block transfers. For Fibre Channel over Ethernet (FCoE), which converges storage and LAN traffic over Ethernet infrastructure, the encapsulation requires an Ethernet MTU of at least 2180 bytes (commonly 2240 or 2500 bytes in practice) to accommodate the full Fibre Channel frame plus Ethernet and FCoE headers, enabling seamless integration without altering the core payload size. The , which runs over TCP/IP, commonly utilizes jumbo frames with an MTU of 9000 bytes in SAN deployments to align with common storage block sizes such as 4 KB or 8 KB, allowing multiple blocks to be transferred in a single packet for reduced fragmentation and improved throughput. This configuration enhances alignment with TCP receive windows by maximizing payload per segment, thereby decreasing the frequency of acknowledgments and header processing, which is particularly beneficial for bandwidth-intensive storage workloads. SAN protocols face challenges related to latency sensitivity, as storage I/O operations demand sub-millisecond response times to avoid bottlenecks in virtualized or database environments; larger MTUs address this by reducing the number of frames processed per transfer, thereby lowering per-I/O latency and boosting overall efficiency through decreased CPU and network overhead. However, implementing larger MTUs requires end-to-end configuration to prevent fragmentation, which could otherwise introduce delays. The FC-BB-5 standard, ratified in the late by the INCITS T11 committee, formalized FCoE for Ethernet convergence, specifying frame handling that supports these adaptations while maintaining Fibre Channel's reliability. Subsequent advancements in NVMe over Fabrics (NVMe-oF), introduced in 2014, extend this to storage, supporting payload sizes up to 4096 bytes over Ethernet transports like RDMA or TCP to optimize for flash-based I/O patterns with minimal latency impact.

Wireless and Mobile Networks

In local area networks (WLANs) adhering to the standard, the maximum size for a MAC (MSDU) is 2304 bytes, serving as the default MTU to balance transmission efficiency with the constraints of the . This limit accommodates the variable nature of channels, where signal interference and can lead to . When an MSDU exceeds the fragmentation threshold—typically set to 2346 bytes by default—the MAC layer fragments it into up to 16 smaller MAC protocol units (MPDUs) for transmission, with reassembly occurring at the receiver to reconstruct the original frame. This mechanism helps mitigate errors in error-prone environments but introduces additional overhead from fragment headers, potentially reducing overall throughput if fragmentation occurs frequently. In cellular networks, such as those based on Long-Term Evolution (LTE) and , the effective MTU for user plane data is generally constrained to 1400-1500 bytes to account for encapsulation overhead in the GPRS Tunneling Protocol-User plane (GTP-U), which adds about 36 bytes including UDP and IP headers. This tunneling is essential for separating user traffic from control signaling across the (RAN) and core, but it reduces the payload capacity compared to wireline links, often leading operators to recommend an MTU of 1420 bytes in to handle extension headers in GTP-U. For ultra-reliable low-latency communication (URLLC) scenarios, which demand sub-millisecond latency for applications like industrial automation, jumbo frames supporting MTUs up to 9000 bytes can be employed to minimize segmentation and processing delays, enhancing efficiency in high-reliability modes. Mobility in and mobile networks introduces challenges for MTU management, as handoffs between access points or base stations alter the end-to-end path, potentially requiring renegotiation of the MTU to prevent blackholing of oversized packets. During these transitions, devices may invoke to probe the new path's capabilities, ensuring compatibility without excessive fragmentation. Protocols like further complicate this by appending 20-52 bytes of additional headers for tunneling via care-of addresses, which decreases the effective and amplifies overhead in bandwidth-limited mobile scenarios, often necessitating proactive MTU adjustments at the network edge. To address these limitations and improve , optimizations such as aggregate MPDU (A-MPDU) in IEEE 802.11n enable the bundling of up to 64 MPDUs—or a total length of bytes—into a single protocol data unit (PPDU), effectively emulating larger MTUs while amortizing access and acknowledgment overheads across multiple subframes. This aggregation is particularly beneficial in interference-heavy mobile environments, where it reduces the number of contention-based transmissions and boosts throughput by up to 50% in high-density scenarios, though it requires careful tuning to avoid amplifying losses from burst errors. Similar techniques in cellular systems, like (PDCP) aggregation in , complement these efforts by concatenating (RLC) service data units before GTP-U encapsulation.

References

  1. https://datatracker.ietf.org/doc/html/rfc791
  2. https://www.cloudflare.com/learning/network-layer/what-is-mtu/
  3. https://www.imperva.com/learn/application-security/what-is-mtu-mss/
  4. https://www.techtarget.com/searchnetworking/definition/maximum-transmission-unit
  5. https://www.networkworld.com/article/745164/mtu-size-issues.html
  6. https://blog.purestorage.com/purely-technical/what-is-mtu-size-and-how-do-you-calculate-it/
  7. https://datatracker.ietf.org/doc/html/rfc1191
  8. https://www.cisco.com/c/en/us/support/docs/ip/generic-routing-encapsulation-gre/25885-pmtud-ipfrag.html
  9. https://datatracker.ietf.org/doc/html/rfc3819
  10. https://datatracker.ietf.org/doc/html/rfc4821
  11. http://www.ece.ucf.edu/~yuksem/teaching/nae/reading/ccr-9501-mogulf1.pdf
  12. https://lostintransit.se/2012/06/06/the-history-of-ethernet-dix-vs-802-3/
  13. https://datatracker.ietf.org/doc/html/rfc8200
  14. https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-G.7041-200312-S!!PDF-E&type=items
  15. https://blog.dave.tf/post/jumbo-frames/
  16. https://www.etsi.org/deliver/etsi_ts/138300_138399/138323/17.04.00_60/ts_138323v170400p.pdf
  17. https://cs.stackexchange.com/questions/52192/in-the-data-link-layer-is-it-better-to-use-large-or-small-frames
  18. https://datatracker.ietf.org/doc/html/rfc1042
  19. https://www.netmaker.io/resources/mtu
  20. https://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus9000/sw/6-x/interfaces/configuration/guide/b_Cisco_Nexus_9000_Series_NX-OS_Interfaces_Configuration_Guide/b_Cisco_Nexus_9000_Series_NX-OS_Interfaces_Configuration_Guide_chapter_010.html
  21. https://datatracker.ietf.org/doc/html/rfc1812
  22. https://datatracker.ietf.org/doc/html/rfc4459
  23. https://datatracker.ietf.org/doc/html/rfc2923
  24. https://datatracker.ietf.org/doc/html/rfc2757
  25. https://fasterdata.es.net/network-tuning/mtu-issues/
  26. http://ethernetalliance.org/wp-content/uploads/2011/10/EA-Ethernet-Jumbo-Frames-v0-1.pdf
  27. https://packetpushers.net/blog/ip-fragmentation-in-detail/
  28. https://datatracker.ietf.org/doc/html/rfc4949
  29. https://datatracker.ietf.org/doc/html/rfc8900
  30. https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/change-default-mtu-size-for-ppp-vpn-connection
  31. https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Troubleshooting_and_Support/Troubleshooting/Troubleshooting_MTU_Issues
  32. https://datatracker.ietf.org/doc/html/rfc1626
  33. https://community.cisco.com/t5/mpls/mtu-related-issues-on-mpls-network/td-p/5164879
  34. https://nickvsnetworking.com/mtu-in-lte-5g-transmission-networks-part-1/
  35. https://www.ieee802.org/11/Reports/tgax_update.htm
  36. https://www.tp-link.com/nordic/support/faq/910/
  37. https://www.rfc-editor.org/rfc/rfc4638.html
  38. https://www.ieee.li/pdf/viewgraphs/exploring_the_ieee_802_ethernet_ecosystem.pdf
  39. https://datatracker.ietf.org/doc/html/rfc8201
  40. https://datatracker.ietf.org/doc/html/rfc2516
  41. https://live.paloaltonetworks.com/t5/globalprotect-articles/troubleshooting-globalprotect-mtu-issues/ta-p/384894
  42. https://gist.github.com/nitred/f16850ca48c48c79bf422e90ee5b9d95
  43. https://github.com/trailofbits/algo/issues/1387
  44. https://datatracker.ietf.org/doc/rfc2625/
  45. https://www.juniper.net/documentation/us/en/software/junos/storage/topics/concept/fibre-channel-fcoe-understanding.html
  46. https://knowledge.broadcom.com/external/article/318937/iscsi-and-jumbo-frames-configuration-on.html
  47. https://www.netapp.com/media/10681-tr4684.pdf
  48. https://www.circle4.com/forsythe/aixperf-ionetwork.pdf
  49. https://www.winlab.rutgers.edu/~zhibinwu/html/wlan_back.htm
  50. https://inet.omnetpp.org/docs/showcases/wireless/fragmentation/doc/index.html
  51. https://www.sonicwall.com/support/knowledge-base/what-is-fragmentation-threshold-and-when-should-we-tweak-fragmentation-threshold/kA1VN0000000Fju0AE
  52. https://www.snbforums.com/threads/optimal-lte-4g-mtu-wan-packet-overhead.74046/
  53. https://github.com/open5gs/open5gs/issues/671
  54. https://www.researchgate.net/publication/389763911_Demystifying_URLLC_in_Real-World_5G_Networks_An_End-to-End_Experimental_Evaluation
  55. https://patentscope.wipo.int/search/en/WO2017142575
  56. https://www.cse.wustl.edu/~jain/cse574-06/ftp/mobile_ip.pdf
  57. https://www.usenix.org/system/files/conference/atc14/atc14-paper-salameh.pdf
  58. https://cse.buffalo.edu/faculty/dimitrio/publications/wowmom18.pdf
Add your contribution
Related Hubs
User Avatar
No comments yet.