Jumbo frame

In computer networking, jumbo frames are Ethernet frames with more than 1500 bytes of payload.[1] Conventionally, jumbo frames can carry up to 9000 bytes of payload, but variations exist and some care must be taken using the term. Many Gigabit Ethernet switches and Gigabit Ethernet network interface cards can support jumbo frames. Some Fast Ethernet switches and Fast Ethernet network interface cards can also support jumbo frames.[2] Most national research and education networks (such as Internet2, National LambdaRail, ESnet, GÉANT and AARNet) support jumbo frames, but most commercial Internet service providers do not.

Inception

Each received Ethernet frame requires that the network hardware and software process it. Increasing the frame size makes a certain large amount of data transferable with less effort, reducing CPU utilization (mostly due to interrupt reduction) and increasing throughput by reducing the number of frames needing processing and reducing the total overhead byte count of all the frames sent.

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

Adoption

Jumbo frames or 9000-byte payload frames have the potential to reduce overheads and CPU cycles.[4] Recent work has also demonstrated the positive effect that jumbo frames have on end-to-end TCP performance.[5] 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 use 4464-byte frames, FDDI can use 4352-byte, ATM can use 9180-byte frames and 802.11 can use 7935-byte frames. The IEEE 802.3 Ethernet standard only mandates support for 1500-byte MTU frames.

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. 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 and with IEEE 802.1Q field). Most Ethernet equipment can support jumbo frames up to 9216 bytes.[6]

Error detection

Larger frames are more likely to suffer undetected errors with the simple CRC32 error detection used in Ethernet frames — a larger amount of data increases the probability that several errors cancel each other out. Consequently, additional mechanisms have been developed to improve error detection on higher network layers.

IETF solutions for adopting jumbo frames avoids the data integrity reductions through use of the Castagnoli CRC polynomial being implemented within the SCTP transport (RFC 4960) and iSCSI (RFC 7143). Selection of this polynomial was based upon work documented in the paper "32-Bit Cyclic Redundancy Codes for Internet Applications".[7] 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.

By using a CRC checksum rather than simple additive checksums as contained within the UDP and TCP transports, errors generated internal to NICs can be detected as well. Both TCP and UDP have proven ineffective at detecting bus specific bit errors, since these errors with simple summations tend to be self-cancelling. Testing that led to adoption of RFC 3309 compiled evidence based upon simulated error injection against real data that demonstrated as much as 2% of these errors were not being detected.

One of the major impediments toward the adoption of jumbo frames has been the inability to upgrade existing Ethernet infrastructure that would be needed to avoid a reduction in the ability to detect errors. CRC calculations done in software have always resulted in slower performance than that achieved when using simple additive checksums, as found with TCP and UDP. To overcome this performance penalty, NICs that off-load SCTP checksum calculations are available, and CPUs that support SSE4.2 can utilize the CRC32c instruction featured in the extension's vector math instruction set.

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 increase of the Ethernet MTU would have otherwise 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) or the maximum transfer unit/MTU (excluding frame headers = maximum layer 3 packet size). Therefore, you might find that different values must be configured in equipment from different vendors to make the settings match. 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.[8]

Bandwidth efficiency

Jumbo frames can slightly raise the efficiency of Ethernet by reducing the overhead, for example with TCP over IPv4:

Frame type MTU Layer 1 overhead Layer 2 overhead Layer 3 overhead Layer 4 overhead Payload size Total transmitted Efficiency
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%

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 jumbo frames are for example required to enable IP/MPLS over Ethernet to deliver Ethernet services. 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.[9] The increased overhead of extra MPLS and Ethernet headers means that the support of 1600 byte frames is a mandatory requirement in Carrier Ethernet Networks.[10]

Super jumbo frames

Super jumbo frames (SJFs) are generally considered to be frames that have a payload size of over 9000 bytes. The relative scalability of network data throughput as a function of packet transfer rates is related in a complex manner [11] to payload size per packet. Generally, as line bit rate increases, the packet payload size should increase in direct proportion to maintain equivalent timing parameters. This however implies the covariant scaling of numerous intermediating logic circuits along the network path, to accommodate the maximum transmission unit (MTU), required. 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 1518 bytes to 9000 bytes or so, a subsequent increase, possibly to 64000 bytes for example, may take some time.

The main factor involved with an increase in the maximum segment size (MSS) is an increase in the available memory buffer size in all of the intervening persistence mechanisms along the path. The main benefit of this is the reduction of the packet rate, both at end nodes and intermediate transit nodes. As the nodes in general use reciprocating logic to handle the packets, the total number of machine cycles spent processing packet headers decreases as the average MSS of the packets increases given a certain total amount of data transmitted. This relationship becomes increasingly important as average network line bit rate increases to 10 gigabits per second, and above.

Partial obsolescence

By making CPU load independent of frame size, large segment offload (LSO) has eliminated the per-packet overhead that jumbo frames were designed to reduce.[12] Large receive offload (LRO), the inbound counterpart of large segment offload, does not quite eliminate per-packet overhead borne by the CPU, therefore jumbo frames remain beneficial for inbound traffic. Jumbo frames are also still useful from a bandwidth perspective as they reduce the amount of bandwidth used for non-data overhead.

See also

References

  1. ↑ "Ethernet Jumbo Frames". Ethernet Alliance. 2009-11-12. Retrieved 2015-06-18.
  2. 1 2 "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. ↑ Jeff Caruso (October 22, 1998). "Alteon still stumping for Jumbo Frames". Network World. Retrieved July 4, 2011.
  4. ↑ Foong, A; T. Huff; H. Hum; J. Patwardhan; G. Regnier (2003). "TCP Performance Re-visited". In IEEE International Symposium on Performance of Systems and Software.
  5. ↑ D Murray; T Koziniec; K Lee; M Dixon (2012). "Large MTUs and internet performance". 13th IEEE Conference on High Performance Switching and Routing (HPSR 2012).
  6. ↑ Scott Hogg (2013-03-06), Jumbo Frames, Network World, retrieved 2013-08-05, Most network devices support a jumbo frame size of 9216 bytes.
  7. ↑ "32-Bit Cyclic Redundancy Codes for Internet Applications" by Philip Koopman, ECE Department & ICES, Carnegie Mellon University
  8. ↑ "What is the Jumbo Frame Supported by Switches and Adapters?". Netgear. Retrieved 2013-08-05.
  9. ↑ RFC-3032, MPLS Label Stack Encoding
  10. ↑ Ceragon, Jumbo Frames: The Microwave Perspective, Technical brief
  11. ↑ 16 000–64 000 B pMTU experiments with simulation: The case for super jumbo frames at Supercomputing ’05
  12. ↑ "Coding Relic: Requiem for Jumbo Frames". 2011-12-07. Retrieved 2011-12-07.

External links

This article is issued from Wikipedia - version of the Tuesday, April 19, 2016. The text is available under the Creative Commons Attribution/Share Alike but additional terms may apply for the media files.