This morning i was wondering about why do we have to make Ethernet Frames a minimum of 64 bytes lenght ? After few research I quickly found about a explaination involving CSMA/CD and collison time but I didn’t founf sothing clear enought to gather all the informations on a same place, so i decided to summarize everything here in case it could help someone asking himslef the same question.
Ethernet Frames layout
First of all so everyone is aligned, here is wath a standard Ethernet Frame looks like. If you want to know more about the Ethernet Header content, have a look here.
So we have 18 bytes uncompressible (14 + 4) for Ethernet overhead, okay fine but there is still room until 64 bytes, why do we have to take 46 bytes from the Payload Data to reach a total minimum of 64 bytes for an Ethernet Frame ?
Let’s go back in time real quick to remind us about the initial context.
Xerox PARC - Robert Metcalfe - 70’s
In 1973, Robert Metcalfe (who joinded PARC in 1972) was tasked to design a network to connect the center’s new personal computers (the Xerox Alto), to a shared laser printer located in the other side of the corridor and “difficult to access”.
This challenge lead to the creation of “Ethernet”, initially introduced under a memo named “Alto Ethernet”, outlining a system that uses coaxial cables and packet switching.
By mid-1975, PARC had installed a robust 100-node Ethernet network.
But one downside of coaxial cables is you can transmit only one signal at a time. If two transmitted simultaneously, a collision would occured.
With their 100-node ethernet network, they had to find a way to avoid these collisions.
CSMA/CD : Carrier Sense Multiple Access with Collision Detection
CSMA was designed to detect ongoing transmissions on coax-cable using carier-sensing so a station can transmit only if no one else is allready transmitting.
Carier-sensing means the station NIC is looking at the coax cable non stop to detect electrical signals (meaning ongoing transmissions).
But if the medium (coax cable) is clear for few micro-seconds, seconds… (idle) multiple stations could start new transmissions at the exact same time, resulting on collisions somewhere on the path.
CD was designed to solve this last problem introducing a “listen while talk” mecanism so while transmitting, the station monitors the medium.
Example: Suppose a station is transmitting a packet. At the most basic level, the packet’s binary data (e.g., 00101110011101001) is converted into electrical signals on the medium.
While transmitting, the station’s NIC also monitors the medium. If it detects a different signal than the one it is sending, for example, 0011111101000001 instead of its own sequence, it means another station has already started transmitting. This overlap indicates a collision.
When a collision is detected, the station sends out a special jam signal (it’s a fixed 32 bit pattern that all stations can clearly recognize). The purpose of the jam signal is to notify every station on the medium that a collision has occurred. Once they receive this signal, all transmitting stations immediately stop sending their frames.
After stopping, each station waits for a random backoff time before trying to retransmit. This randomized delay helps reduce the chance of repeated collisions on the shared medium.
All of this works because our transmitting station can detect a collision while it is still sending its own frame. If it were not transmitting, it would simply wait until the medium was free before sending.
This detail is crucial : imagine a remote station sending us a very small frame. If that station finishes transmitting before the first bit of its frame even reaches our station, then by the time our station detects the collision and sends the jam signal, the remote station is already done transmitting. In this case, the remote station will ignore the jam signal, because jam signals are only meaningful to stations that are actively transmitting at that moment.
So to sums up, we know that for a collision to be detected, a full frame transmission from Station A must take longer than the time it takes for the first bit to travel across the medium to Station B, plus the time it would take for Station B to send back a jam signal to A. This ensures that Station A is still in the process of transmitting when the jam signal arrives.
Things are well designed, because we have a term to define this round-trip time.
Slot time and Bit time
Bit Time is defined as the time it takes for one bit to be ejected from a network interface controller (NIC) operating at some predefined standard speed.
In our 70’ context, the NICs were 10Mbis/s speed. Let’s calculate their bit time : 1 / (10 * 10^6) = 100 nanoseconds
Slot Time is at least twice the time it takes for an electronic pulse (OSI Layer 1 - Physical, consider a bit) to travel the length of the maximum theoretical distance between two nodes.
Note that Slot Time is only applicable to these half-duplex transmissions because with full-duplex we would not have to wait for the medium to be free.
But, as coax cable size and quality can vary based on the network, the IEEE defined a “constant Slot Time value” that an electronic pulse would need to round-trip the worst possible coax cable (like more than 300m, some attenuation, worst propagation delay, margin etc) so that the “real” slot time is always lower. This constant for 10 Mbit/s NIC is 51,2 μs.
Then, if our transmission must last at least 51,2 microseconds and we know that we can send 1 bit every 100 nanoseconds, we can now calculate how much bits this would represent.
Let’s do the math : 51,2 x 10^-6 / 100 x 10^-9 = 51,2/0,1 = 512 bits = 64 bytes
Here they are, today’s Ethernet Frames have to be minimum 64 bytes long beacause of a constraint they had 50 years ago with half-duplex networks.
This prerequiste is now part of the Ethernet standard and at least it allows retro-compatibility with legacy half-duplex environements.
Sources :
- Slot-Time : https://en.wikipedia.org/wiki/Slot_time
- Bit-Time : https://en.wikipedia.org/wiki/Bit_time
- Ethernet standards : https://en.wikipedia.org/wiki/Ethernet_frame