Why was the MTU size for ethernet frames calculated as 1500 bytes?

Question

Why was ethernet MTU calculated as 1500 bytes?

What specific calculation was done to arrive at 1500 byte ethernet MTUs, and what factors were considered for that calculation?

Answer 1

padmaraj asked:

Why was ethernet MTU calculated as 1500 bytes?

What specific calculation was done to arrive at 1500 byte ethernet MTUs, and what factors were considered for that calculation?

Short story

The answer to "Why is Ethernet MTU calculated as 1500 bytes?" is layered. A lot depends on the Ethernet protocols in question. Unfortunately we don't always know in advance what Layer-2 protocol is wrapped by an Ethernet frame header.

Ethernet uses the two / four bytes after the source mac-address in different ways:

• 802.1Q tagged frames use the FOUR bytes following the source mac-address as a vlan tag. 802.1Q is EtherType 0x8100
• Untagged Ethernet II DIX frames use TWO bytes after the Ethernet source mac-address for a EtherType
• 802.3 frames (such as 802.2 ISIS / Spanning-Tree) use TWO bytes after the Ethernet source mac-address as a Length field.

How do you know which Ethernet Layer-2 protocol we're parsing off the wire? Usually, we know from the MAC-layer EtherType, but 802.3 with 802.2 LLC encap doesn't have an EtherType.

Thus, the payload of ISO 802.2 LLC frames (such as ISIS or Spanning-Tree) should not exceed 1500 bytes. Other Ethernet protocols (such as Ethernet II DIX) unofficially can exceed 1500 bytes as long as their Ethernet PHY-layer doesn't depend on CSMA/CD.

Longer story

A lot depends on the Ethernet protocols in question. The most basic technique to read Ethernet headers is explained in draft-ietf-isis-ext-eth-01, specifically Section 3-5. Quoting from that RFC draft...

5. Problem with Large Length interpretation Frames in the presence of Type Interpretation Frames
   
   Some protocols commonly used in the Internet have no reserved EtherType. An example is the set of ISO Network layer protocols, of which ISIS is a member. Such protocols are only defined to use the IEEE 802.3/802.2 encoding, and so their packets are limited in length to 1500 bytes.
   
   Type Interpretation frames have no length field. Protocols encapsulated in Type interpretation frames, such as IP, are not limited in length to 1500 bytes by framing.

I'm including an annotated diagram below of Ethernet II DIX and 802.3 frames, these illustrate where the conflicting bytes are in the ethernet header:

• RFC 894 Ethernet II (DIX) frames have an EtherType after the source mac-address

      +----+----+-----------+------+-----+
      | DA | SA | EtherType | Data | FCS |
      +----+----+-----------+------+-----+
                ^^^^^^^^^^^^^
  
      DA           Destination MAC Address (6 bytes)
      SA           Source MAC Address      (6 bytes)
      EtherType    Protocol                (2 bytes: >= 0x0600 or 1536 decimal)  <---
      Data         Protocol Data           (46 - 1500 bytes)
      FCS          Frame Checksum          (4 bytes)
  

• IEEE 802.3 with ISO 802.2 LLC / SNAP (used by [Spanning-Tree], ISIS) use these same bytes for Length; 802.2 ISO ISIS doesn't have an EtherType and Spanning-Tree doesn't have an EtherType. Therefore 802.2 frame payloads MUST be smaller than 1500 bytes in order for the Length field to avoid conflict with reserved EtherType values.

      +----+----+------+-------------------------+------------+
      | DA | SA | Len  | DSAP / SSAP / Ctl (DSC) | Data | FCS |
      +----+----+------+-------------------------+------------+
                ^^^^^^^^
  
      DA      Destination MAC Address (6 bytes)
      SA      Source MAC Address      (6 bytes)
      Len     Length of Data field    (2 bytes: <= 0x05DC or 1500 decimal)  <---
      DSC     802.2 DSAP, SSAP, Ctl   (3 bytes)
      Data    Protocol Data           (46 - 1500 bytes)
      FCS     Frame Checksum          (4 bytes)
  

IEEE's objections to official Jumbo frame support

    General comments on the use of jumbo frames in Ethernet networks:

    Consideration #1: The expectation of no more than 15-1600 bytes
    between frames and an interpacket gap before the next frame is
    deeply ingrained throughout the design and implementation of
    standardized Ethernet/802.3 hardware. This shows up in buffer
    allocation schemes, clock skew and tolerance compensation and fifo
    design.

    Consideration #2: For some Ethernet/802.3 hardware (repeaters are
    one specific example) it is not possible to design compliant
    equipment which meets all of the requirements and will still pass
    extra long frames.  Further, since clock frequency may vary with
    time and temperature, equipment may successfully pass long frames
    at times and corrupt them at other times.  Therefore, attempts to
    verify the ability to send long frames over a path may produce
    inaccurate results.

    Consideration #3: The error checking mechanism embodied in the 4
    byte checksum has not been well characterized at greater frame
    lengths, but is known to degrade. Therefore the data reliability of
    transfers in long frame transfers will have a greater rate of
    undetected frame errors.

    Consideration #4: The length of frames proposed by this draft can
    not be assured to pass through standards conformant hardware. The
    huge value of Ethernet/802.3 systems in the data networking
    universe is their standardization and the resulting assurance that
    systems will all interoperate. No such assurance can be provided
    for oversize frames with both the current broadly accepted standard
    and the large installed base ofstandards based equipment.

    In summary with regard to greatly longer frames for Ethernet, much
    of the gear produced today would be intolerant of greatly longer
    frames.  There is no way proposed to distinguish between frame
    types in the network as they arrive from the media. Bridges might
    and repeaters would drop or truncate frames (and cause errors doing
    so) right and left for uncharacterized reasons. It would be a
    mess. What might seem okay for small carefully characterized
    networks would be enormously difficult or impossible to do across
    the Standard.

Summary

The safest Ethernet MTU is 1500-byte payloads; IEEE refuses to endorse Ethernet payloads > 1500 bytes. Depending on circumstances, we can CAUTIOUSLY increase Ethernet II payloads over the existing MTU of 1500-bytes.

If you want to implement jumbo frames (MTU > 1500), you should test your network to ensure you aren't breaking things in subtle ways. Thoroughly read IEEE's objections to jumbo frames (see above) before you test.

I will summarize with some simple guidance around jumbo frame support:

• Ethernet 802.2 LLC ISIS / Spanning-Tree frames must NOT exceed a 1500-byte payload (to avoid EtherType / frame Length conflicts).
• Ethernet II DIX frame payloads CAN exceed 1500 bytes on full-duplex links
• Ethernet II DIX frame payloads must NOT exceed 1500 bytes on half-duplex links, which use CSMA/CD (and Ethernet CSMA/CD assumes the payload is <= 1500 bytes)
• 802.1Q Frames cannot use 802.3 / 802.2 encapsulation, and 802.1Q frame payloads CAN exceed 1500 bytes on full-duplex links.

As mentioned above, if you implement jumbo frames, test to ensure you aren't breaking things.

FYI, I am including a link to pdf copies of the Ethernet Version 1 spec and Ethernet Version 2 spec, in case anyone is interested...

Answer 2

At the other end of the range - 1500 bytes, there were two factors that lead to the introduction of this limit. First, if the packets are too long, they introduce extra delays to other traffic using the Ethernet cable. The other factor was a safety device built into the early shared cable transceivers. This safety device was an anti-babble system. If the device connected to a transceiver developed a fault and started transmitting continuously, then it would effectively block any other traffic from using that Ethernet cable segment. To protect from this happening, the early transceivers were designed to shut off automatically if the transmission exceeded about 1.25 milliseconds. This equates to a data content of just over 1500 bytes. However, as the transceiver used a simple analogue timer to shut off the transmission if babbling was detected, then the 1500 limit was selected as a safe approximation to the maximum data size that would not trigger the safety device.

Source: http://answers.yahoo.com/question/index?qid=20120729102755AAn89M1

Answer 3

When Ethernet was originally developed as a shared medium or bus with 10Base5 and 10Base2, collisions of frames were frequent (what else you would expect in a connection where you fork the signal by drilling a tap into the cable) and expected as part of the design. Contrast this to today, when most everything is switched with separate collision domains and running full-duplex, where no one expects to see collisions.

The mechanism to share the "ether" employed CSMA/CD (Carrier Sense Multiple Access/Collision Detection)

Carrier Sense meant that a station wanting to transmit must listen to the wire -- sense the carrier signal -- to ensure no one else was talking since it was Multiple Access on that medium. Allowing 1500 bytes (though an arbitrary number as far as I can tell) was a compromise that meant a station could not capitalize the wire too long by talking too much at one time. The more bytes transmitted in a frame, the longer all other stations must wait until that transmission completes. In other words, shorter bursts or smaller MTU meant other stations got more opportunity to transmit and a fairer share. The slower the rate of the transmission medium (10Mb/s), stations would have longer delays to transmit as the MTU increases (if allowed to exceed 1500).

An interesting corollary question would be why the minimum frame size of 64 bytes? Frames were transmitted in "slots" that are 512 bits and took 51.2 microseconds for round-trip signal propagation in the medium. A station has to not only listen to when to start talking by sensing the IFG (interframe gap of 96 bits), but to listen for collisions with other frames. Collision Detection assumes maximum propagation delay and doubles that (to be safe) so it doesn't miss a transmission starting about the same time from the other end of the wire or a signal reflection of its own transmission when someone forgot the terminating resistor at the ends of the cable. The station must not complete the sending of its data before sensing a collision, so waiting 512 bits or 64 bytes guarantees this.

Answer 4

Originally, max. payload was defined as 1500 bytes in 802.3. Ethernet v2 supports frame length of >=1536 and this is what IP implementations use. Most carrier-class vendors support around 9000 bytes ("jumbo frames") these days. Since 1500 byte is the standard that all Ethernet implementations must support, this is what is normally set as default on all interfaces.

Answer 5

The minimum ethernet frame is based on the Ethernet Slot Time, which is 512 bit lengths (64 Bytes) for 10M ethernet. After subtracting 18 bytes for the ethernet header and CRC, you get 46 bytes of payload.

Ethernet Slot Time was specified so CSMA/CD would correctly function. One must be sure that the minimum frame size does not exceed the longest possible length of cable; if it did deterministic collision detection would be impossible. After collision detection at the maximum length of cable, you need the collision detection signal to return to the sender.