Is there any specific calculation that that was done to arrive at this number, and what were the factors that were taken into consideration for that calculation.
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.
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.
When Ethernet was originally developed as a shared medium or bus with 10Base5 an 10Base2, collisions of frames were frequent 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 CMSA/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.2us 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.
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.
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.