Jump to content

Jumbo frame

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by A876 (talk | contribs) at 20:35, 10 March 2021 (+"in 1998" from ref. 2 wordings. checked some links. rescued 1 link. marked dead 1 link.). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

In computer networking, jumbo frames are Ethernet frames with more than 1500 bytes of payload, the limit set by the IEEE 802.3 standard.[1] Commonly, jumbo frames can carry up to 9000 bytes of payload, but smaller and larger variations exist and some care must be taken using the term. Many Gigabit Ethernet switches and Gigabit Ethernet network interface controllers can support jumbo frames. Some Fast Ethernet switches and Fast Ethernet network interface cards can also support jumbo frames.[2]

Inception

Each Ethernet frame must be processed as it passes through the network. Processing the contents of a single large frame is preferable to processing the same content broken up into smaller frames, as this makes better use of available CPU time by reducing interrupts. This also minimizes the overhead byte count and reduces the number of frames needing to be processed.[3] This is analogous to physically mailing a packet of papers instead of several single envelopes with one sheet each, saving envelopes and cutting sorting time.

Jumbo frames gained initial prominence in 1998, when Alteon WebSystems introduced them in their ACEnic Gigabit Ethernet adapters.[4] Many other vendors also adopted the size; however, jumbo frames are not part of the official IEEE 802.3 Ethernet standard.

Adoption

Jumbo frames have the potential to reduce overheads and CPU cycles[5] and have a positive effect on end-to-end TCP performance.[6] The presence of jumbo frames may have an adverse effect on network latency, especially on low-bandwidth links. The frame size used by an end-to-end connection is typically limited by the lowest frame size in intermediate links. 802.5 Token Ring can support frames with a 4464-byte MTU, FDDI can transport 4352-byte, ATM 9180-byte and 802.11 can transport 7935-byte MTUs. The IEEE 802.3 Ethernet standard originally mandated support for 1500-byte MTU frames, 1518 byte total frame size (1522 byte with the optional IEEE 802.1Q VLAN/QoS tag). The IEEE 802.3as update grandfathered in multiple common headers, trailers, and encapsulations by creating the concept of an envelope where up to 482 bytes of header and trailer could be included, and the largest IEEE 802.3 supported Ethernet frame became 2000 bytes.

The use of 9000 bytes as preferred payload size for jumbo frames arose from discussions within the Joint Engineering Team of Internet2 and the U.S. federal government networks.[7] Their recommendation has been adopted by all other national research and education networks. In order to meet this mandatory purchasing criterion, manufacturers have in turn adopted 9000 bytes as the conventional MTU size, with a jumbo frame size of at least 9018/9022 bytes (without/with IEEE 802.1Q field).[citation needed] Most Ethernet equipment can support jumbo frames up to 9216 bytes.[8]

IEEE 802.1AB-2009 and IEEE 802.3bc-2009 added LLDP discovery to standard Ethernet for maximum frame length (TLV subtype 4).[9] It allows frame length detection on a port by a two-octet field. As of IEEE 802.3-2015, allowed values are 1518 (only basic frames), 1522 (802.1Q-tagged frames), and 2000 (multi-tagged, envelope frames).[10]

Error detection

Simple additive checksums as contained within the UDP and TCP transports have proven ineffective at detecting bus-specific bit errors because with simple summations, these errors tend to self-cancel. Before the adoption of RFC 3309, testing with simulated error injection against real data showed that as much as 2% of these errors were not being detected.

Larger frames are more likely to suffer undetected errors with the simple CRC32 error detection used in Ethernet frames – as packet size increases it becomes more likely that multiple errors cancel each other out.[a]

One IETF approach for adopting jumbo frames avoids data integrity reduction of the service data unit by performing an extra CRC at the next network protocol layer above Ethernet. Stream Control Transmission Protocol (SCTP) transport (RFC 4960) and iSCSI (RFC 7143) use the Castagnoli CRC polynomial. The Castagnoli polynomial 0x1EDC6F41 achieves the Hamming distance HD=6 beyond one Ethernet MTU (to a 16,360-bit data word length) and HD=4 to 114,663 bits, which is more than 9 times the length of an Ethernet MTU. This gives two additional bits of error detection ability at MTU-sized data words compared to the Ethernet CRC standard polynomial while not sacrificing HD=4 capability for data word sizes up to and beyond 72 kbits.[12] Support of Castagnoli CRC polynomial within a general-purpose transport designed to handle data chunks, and within a TCP transport designed to carry SCSI data, both provide improved error detection rates despite the use of jumbo frames where an increase of the Ethernet MTU would otherwise have resulted in a significant reduction in error detection.

Configuration

Some vendors include the headers in the size settings while others do not, that is either the maximum frame size (including frame headers, maximum layer-2 packet size) or the maximum transmission unit (maximum layer 3 packet size excluding frame headers). Therefore, you might find that different values must be configured in equipment from different vendors to make the settings match.[citation needed]

A mixture of devices configured for jumbo frames and devices not configured for jumbo frames on a network has the potential to cause network performance issues.[13]

Bandwidth efficiency

Jumbo frames can increase the efficiency of Ethernet and network processing in hosts by reducing the protocol overhead, as shown in the following example with TCP over IPv4. The processing overhead of the hosts can potentially decrease by the ratio of the payload sizes (approximately six times improvement in this example). Whether this is significant depends on how packets are processed in the host. Hosts that use a TCP offload engine will receive less benefit than hosts that process frames with their CPU.

Frame-level bandwidth efficiency
Frame type MTU Layer 1 overhead Layer 2 overhead Layer 3 overhead Layer 4 overhead Payload size Total transmitted[A] Efficiency[B]
Standard 1500 preamble
8 byte		 IPG
12 byte		 frame header
14 byte		 FCS
4 byte		 IPv4 header
20 byte		 TCP header
20 byte		 1460 byte 1538 byte 94.93%
Jumbo 9000 preamble
8 byte		 IPG
12 byte		 frame header
14 byte		 FCS
4 byte		 IPv4 header
20 byte		 TCP header
20 byte		 8960 byte 9038 byte 99.14%
Other frame sizes for reference
IEEE 802.11[14][15] 7935 PLCP preamble & header
24 byte		 IPG
varies		 frame header & security ovhd
52 byte		 FCS
4 byte		 IPv4 header
20 byte		 TCP header
20 byte		 7895 byte 8015 + IPG size byte < 98.5%
IEEE 802.11 bridged to Ethernet 1500 PLCP preamble & header
24 byte		 IPG
varies		 frame header & security ovhd
52 byte		 FCS
4 byte		 IPv4 header
20 byte		 TCP header
20 byte		 1460 byte 1580 + IPG size byte < 92.4%
  1. ^ Total transmitted size is the sum of the payload size and all overhead sizes.
  2. ^ Efficiency is calculated by dividing the payload size by the total transmitted size.

The relative scalability of network data throughput as a function of packet transfer rates is related in a complex manner to payload size per packet.[16] Generally, as line bit rate increases, the packet payload size should increase in direct proportion to maintain equivalent timing parameters. This however implies the scaling of numerous intermediating logic circuits along the network path to accommodate the maximum frame size required.

Baby giant frames

Baby giant or baby jumbo frames are Ethernet frames that are only slightly larger than allowed by the IEEE Ethernet standards.[2] Baby giant frames are, for example, required for IP/MPLS over Ethernet to deliver Ethernet services with standard 1500 byte payloads. Most implementations will require non-jumbo user frames to be encapsulated into MPLS frame format which in turn may be encapsulated into a proper Ethernet frame format with EtherType values of 0x8847 and 0x8848.[17] The increased overhead of extra MPLS and Ethernet headers means that the support for frames up to 1600 bytes is required in Carrier Ethernet networks.[18]

Super jumbo frames

Super jumbo frames (SJFs) are frames that have a payload size over 9000 bytes. As it has been a relatively difficult, and somewhat lengthy, process to increase the path MTU of high-performance national research and education networks from 1500 bytes to 9000 bytes or so, a subsequent increase, possibly to 64,000 bytes, is under consideration. The main factor involved with an increase in the maximum segment size (MSS) is an increase in the available memory buffer size in every intervening persistence mechanism along the path.

Alternate approach

Large send offload and large receive offload offload per-frame processing making CPU load largely independent of frame size. It is another way to eliminate the per-packet overhead that jumbo frames were designed to reduce.[19] Jumbo frames are still useful from a bandwidth perspective, as they reduce the amount of bandwidth used for non-data overhead.

See also

Notes

  1. ^ Matt Mathis has discussed whether this is actually a practical problem, arguing that the reduced packet count for jumbo frames counteracts the higher undetected error rate.[11]

References

  1. ^ "Ethernet Jumbo Frames" (PDF). Ethernet Alliance. 2009-11-12. Retrieved 2015-06-18.
  2. ^ a b "Jumbo/Giant Frame Support on Catalyst Switches Configuration Example". Cisco. Retrieved 2011-08-22. Catalyst 3750/3560 Series switches support an MTU of 1998 bytes for all 10/100 interfaces
  3. ^ "Ethernet Jumbo Frames" (PDF). EthernetAlliance.org. Retrieved April 28, 2017.
  4. ^ Jeff Caruso (October 22, 1998). "Alteon still stumping for Jumbo Frames". Network World. Archived from the original on 2012-10-15. Retrieved July 4, 2011.
  5. ^ Foong, A; T. Huff; H. Hum; J. Patwardhan; G. Regnier (2003). "TCP Performance Re-visited". 2003 IEEE International Symposium on Performance Analysis of Systems and Software. ISPASS 2003. pp. 70–79. doi:10.1109/ISPASS.2003.1190234. ISBN 978-0-7803-7756-1.
  6. ^ D Murray; T Koziniec; K Lee; M Dixon (2012). "Large MTUs and internet performance". 2012 IEEE 13th International Conference on High Performance Switching and Routing. pp. 82–87. doi:10.1109/HPSR.2012.6260832. ISBN 978-1-4577-0833-6.
  7. ^ Rick Summerhill (17 Feb 2003), rrsum-almes-mtu, Internet2
  8. ^ Scott Hogg (2013-03-06), Jumbo Frames, Network World, retrieved 2013-08-05, Most network devices support a jumbo frame size of 9216 bytes.
  9. ^ IEEE 802.3 79.3.4 Maximum Frame Size TLV
  10. ^ IEEE 802.3 3.2.7 MAC Client Data field
  11. ^ Mathis, Matt (2016-10-08). "Arguments about Internet MTU". web.archive.org. Archived from the original on 2016-10-08. Retrieved 2019-08-23.
  12. ^ Philip Koopman. "32-Bit Cyclic Redundancy Codes for Internet Applications" (PDF). ECE Department & ICES, Carnegie Mellon University.
  13. ^ "Guidance on the use of jumbo frames". Netgear. Retrieved 2020-03-21.
  14. ^ Philip (October 20, 2016). "Wireless Network Speed Tweaks". speedguide.net. Retrieved October 20, 2016.
  15. ^ IEEE 802.11-2012 8.2.3 General frame format
  16. ^ Rutherford, W.; Jorgenson, L.; Siegert, M.; Van Epp, P.; Liu, L. (2007). "16000–64000 B pMTU experiments with simulation: The case for super jumbo frames at Supercomputing '05". Optical Switching and Networking. 4 (2): 121–130. doi:10.1016/j.osn.2006.10.001.
  17. ^ RFC-3032, MPLS Label Stack Encoding
  18. ^ Ceragon, Jumbo Frames: The Microwave Perspective, Technical brief Archived 2012-09-15 at the Wayback Machine
  19. ^ "Coding Relic: Requiem for Jumbo Frames". 2011-12-07. Retrieved 2011-12-07.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Jumbo_frame&oldid=1011424899"