...

On current research networks (and most other parts of the Internet), end nodes (hosts) are restricted to a 1500-byte IP Maximum Transmission Unit (MTU). Because a larger MTU would save effort on the part of both hosts and network elements - fewer packets per volume of data means less work - many people have been advocating efforts to increase this limit, in particular on research network initiatives such as Internet²andG�ANT Internet² and GÉANT.

Impact of Large Packets

Improved Host Performance for Bulk Transfers

It has been argued that TCP is most efficient when the payload portions of TCP segments match integer multiples of the underlying virtual memory system's page size - this permits "page flipping" techniques in zero-copy TCP implementations. A 9000 byte MTU would "naturally" lead to 8960-byte segments, which doesn't correspond to any common page size. However, a TCP implementation should be smart enough to adapt segment size to page sizes where this actually matters, for example by using 8192-byte segments even though 8960-byte segments are permitted. In addition, Large Send Offload (LSO), which is becoming increasingly common with high-speed network adapters, removes the direct correspondance correspondence between TCP segments and driver transfer units, making this issue moot.

On the other hand, Large Send Offload (LSO) and Interrupt Coalescence remove most of the host-performance motivations for large MTUs: The semgentation segmentation and reassembly function between (large) application data units and (smaller) network packets is mostly moved to the network interface controller.

...

Network Support for Large MTUs

Research Networks

The G�ANT/G�ANT2 and Abilene GÉANT and most other Research and Education backbones now both support a 9000-byte IP MTU. The current  The access MTUs of Abilene connectors can be found on the Abilene Connector Technology Support page. The access MTUs of the NRENs to G�ANT GÉANT are listed in the G�ANT GÉANT Monthly Report (not publicly available).

...

On some NICs it's possible to configure jumbo frames (for example MTU=9000) and the NIC is working fine when checking it's functionality with pings (jumbo sized ICMP packets), altough although the NIC vendor states there is no jumbo frame support.
In that cases there are packet losses on the NIC if it receives jumbo frames with typical production data rates.

Therefore the NIC vendor information should be consulted before activating Large MTUs on the host interface. Then high data rate tests should be done with large MTUs. The hosts interface statistics should be checked on input packet drops.
Typical commands on unix systems: 'ifconfig <ifname>' or 'ethtool -S <ifname>'

---

References

• Raising the Internet MTU, M. Mathis
• Increasing MTU in Research Networks, S. Leinen, TF-NGN Presentation, January 2004
• "Jumbo Frames? No!", B. Daines, NetworkWorldFusion, March 1998
• Jumbo MTU Issues, presentation by L. Jorgenson to the ESCC/Internet2 Joint Techs Workshop, 2004
• "Jumbo" Frames and Internet2, Web page explaining the Internet2 configuration. Contains many pointers.
• Gigabit Ethernet Jumbo Frames And why you should care, P. Dykstra, Dec 1999
• End-System Optimizations for High-Speed TCP, J. Chase, A. Gallatin, K. Yocum, 2001 (variant appeared in IEEE Communications Magazine)
• MTU ("jumbo frames") Recommendation for LHCONE and LHCOPN, S. McKee, M. O'Connor, E. Martelli, presentation, Umeå, June 2019

Vendor-specific

• Cisco: Jumbo/Giant Frame Support on Catalyst Switches, CCO Document ID: 24048Sun: Enabling jumbo frames for Sun x8 Quad NIC Note: In 2009, Sun has radically changed the way that link-specific parameters are configured in Solaris - the dladm command is now used for this. See e.g. this thread.
  -- Main.SimonLeinen - 16 Mar 2005 - 02 Sep 2009
  -- Main.HankNussbacher - 18 Jul 2005

Simon Leinen – 2005-03-16 – 2021-09-09

Hank Nussbacher – 2005-07-18 (added Phil Dykstra paper)