Ethernet – Why is the Data Frame Size Limited to 1500 Bytes?

ethernetmtu

I am still not sure why the Ethernet data frame size / MTU was set maximum to 1500 bytes. I found out a document from Xerox which is from 1980. Available at (http://www.pennington.net/archives/ethernet/Ethernet_Version_1.pdf).

At point 6.2.3 it says that

The data field contains a sequence of n octets, where 46 < n < 1500 Within this range, full data transparency is provided, in the sense that any arbitrary sequence of octet values may appear in the data field.

I am not fully understand the reason that provided in this documentation. How does full data transparency provided? Is there any calculations behind this?

Anyone can share to me?

Best Answer

"Data transparency" in this context means that Ethernet doesn't care what kind of data it transports. You put any payload in a frame, send it to the destination and extract the exact same payload.

Initially, the maximum frame size was a trade-off between efficiency and latency. The larger a frame, the lower the overhead, the better the effiency. However, early Ethernet was a shared medium, so any frame in transit occupied the whole segment - the longer the frame, the longer the network was blocked and other senders had to wait. Additionally, early Ethernet NICs required fast local memory for buffering a frame. Ethernet was aiming to reduce prices, so then-expensive RAM had to be kept at a reasonable minimum.

When switches were introduced in the early 1990s, the maximum size had to be kept for compatibility reasons: a sender has no way to tell whether the frames it sends are going over a shared medium (anywhere) or whether they are switched at all times. Hardware buffers have to sized to maximum frame size as well and can't change on the fly.

Related Solutions

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

The answer is in draft-ietf-isis-ext-eth-01, Sections 3-5. Ethernet uses the same two bytes different ways in the Ethernet II (DIX) and 802.3 encapsulations:

Ethernet II uses the first two bytes after the Ethernet source mac-address for a Type
802.3 uses those same two bytes for a Length field.

I'm including an annotated diagram below of each frame type, which shows exactly where the conflicting bytes are in the ethernet header:

RFC 894 (commonly known as Ethernet II frames) use these bytes for Type

    +----+----+------+------+-----+
    | DA | SA | Type | Data | FCS |
    +----+----+------+------+-----+
              ^^^^^^^^

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

IEEE 802.3 with 802.2 LLC / SNAP (used by Spanning-Tree, ISIS) use these bytes for Length

    +----+----+------+------+-----+
    | DA | SA | Len  | 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)  <---
    Data    Protocol Data           (46 - 1500 bytes)
    FCS     Frame Checksum          (4 bytes)

Both Ethernet II and 802.3 encapsulations must be able to exist on the same link. If IEEE allowed Ethernet payloads to exceed 1536 bytes (0x600 hex), then it would be impossible to distinguish large 802.3 LLC or SNAP frames from Ethernet II frames; ethernet's Type values start at 0x600 hex.

EDIT:

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

Ethernet – Why is the ethernet payload fixed between 46 and 1500 bytes

The reason for 46 byte payloads:

According to paragraph 6.3.2.3 of the Ethernet V2 Spec, the minimum ethernet frame is based on the Ethernet Slot Time, which is 512 bit lengths (64 Bytes) for 10M ethernet. Slot time governs both maximum cable length and minimum frame size.

After subtracting 18 bytes for the ethernet header and CRC, you get 46 bytes of Ethernet payload as the minimum payload size.

Slot time (and thus the minimum frame size) is also closely related to Ethernet collision detection. Quoting An Introduction to Computer Networks, paragraph 2.1.2:

... a collision can be received, in principle, at any point up until the end of the slot time. As a result, Ethernet has a minimum packet size, equal to the slot time, ie 64 bytes (or 46 bytes in the data portion). A station transmitting a packet this size is assured that if a collision were to occur, the sender would detect it (and be able to apply the retransmission algorithm, below). Smaller packets might collide and yet the sender not know it, ultimately leading to greatly reduced throughput

Ethernet Slot Time was specified so CSMA/CD would correctly function. The minimum size of a frame is defined to make sure that its transmission takes enough time so that even with a shortest valid frame, a possible collision can be reliably detected; if the frame size is too small (with respect to the maximum cable length), deterministic collision detection would be impossible.

1500 byte payloads:

We have already discussed the reason for 1500 byte MTUs; please refer to that question for specifics.

Note: ytti's comment about the FCS limitation of ethernet is not the reason that 1500 bytes was chosen. It was chosen due to issues with interpreting the Length field in 802.3 encap frames vs the Type field in Ethernet II frames.