L2 Forwarding & the 64-Byte Minimum

A favorite trading-desk question: can you send an Ethernet frame smaller than 64 bytes — if so how, and why does the 64-byte floor exist in the first place?

The short version, so you can lead with it and then defend it: on a normal NIC you cannot put a sub-64-byte frame on the wire — the MAC pads the payload with zeros up to the 64-byte minimum, and any conformant switch that receives an undersized frame drops it as a runt. The 64-byte floor is a legacy of CSMA/CD collision detection on half-duplex shared Ethernet; on modern full-duplex switched links it is technically unnecessary but retained for backward compatibility. The nuance an interviewer wants is why 64, and the honest edge cases where a shorter frame can exist on the wire.

Answer in three beats: (1) the number comes from the CSMA/CD slot time = 512 bit-times = 64 bytes, sized so a station is still transmitting when the worst-case collision returns; (2) below 64 bytes is a runt — NICs pad up, switches drop; (3) full-duplex killed the reason but not the rule, and cut-through switches / custom FPGA hardware are the "yes-but" exceptions.

Ethernet frame anatomy — where 64 comes from

An Ethernet II frame on the wire, field by field. Note the split: the preamble + SFD and the inter-frame gap are physical-layer overhead and are not counted in the frame size; the "frame" for the 64-byte rule runs from the destination MAC through the FCS.

Do the arithmetic on the fixed overhead:

header + trailer  =  DST(6) + SRC(6) + Type(2) + FCS(4)  =  18 bytes

minimum frame     =  18 (overhead) + 46 (min payload)     =  64 bytes
maximum frame     =  18 (overhead) + 1500 (max payload)   =  1518 bytes  (1522 with a 802.1Q VLAN tag)

So the 46-byte minimum payload is not a fundamental number — it is whatever is left after you subtract the 18 bytes of header and FCS from the 64-byte minimum frame. The real constraint is the 64.

Why 64 bytes? CSMA/CD and the slot time

The number is a physics constraint from half-duplex shared Ethernet, where many stations share one collision domain and arbitrate with CSMA/CD (Carrier Sense Multiple Access with Collision Detection). A sender must be able to detect that its frame collided with another station's frame — and it can only detect a collision while it is still transmitting. Once the last bit has left the NIC, the transmitter has moved on and will never learn the frame was destroyed.

The worst case is two stations at opposite ends of the maximum-diameter segment. Station A starts sending; its signal takes the one-way propagation delay to reach B. B senses idle right before A's signal arrives and also starts. The collision happens near B, and the collision signal must now travel all the way back to A. So A must still be transmitting after a full round trip:

A ●══════════════════════ max segment ══════════════════════● B
  │                                                          │
  │──── A's frame propagates (one-way delay) ───────────────▶│  B starts just now → COLLISION
  │◀─── collision jam propagates back to A (one-way delay) ──│
  │                                                          │
  └────────── round-trip time = the SLOT TIME ──────────────┘
          A must STILL be sending when the jam arrives.

That round-trip budget is the slot time. For 10/100 Mbit/s Ethernet it was standardized at:

slot time = 512 bit-times = 64 bytes

At 10 Mbit/s:  512 bits / 10e6 b/s = 51.2 microseconds  round-trip budget
               → covers ~2500 m of cable + up to ~5 repeaters (the classic 5-4-3 rule)

If the frame carried fewer than 512 bits of payload+header, a station could finish transmitting before the collision signal got back to it. It would consider the frame successfully sent, never retransmit, and the data would be silently lost. That failure mode has a name: a late collision — a collision detected after the first 64 bytes (i.e., after the slot time), which the sender does not automatically retransmit. The 64-byte minimum is precisely what guarantees collisions are always detected inside the slot time and are therefore recoverable.

Runts and padding — why you can't just emit a short frame

Two mechanisms enforce the floor, one on transmit and one on receive:

• Padding (transmit): if an upper layer hands the MAC fewer than 46 payload bytes (e.g. a bare ARP request, or a TCP ACK with no data — an IP+TCP header alone is ~40 bytes), the NIC/MAC pads with zeros up to 46 so the frame reaches 64 bytes. The FCS is computed over the padded frame. This is automatic and happens below the driver, which is why on a standard NIC you literally cannot put a sub-64-byte frame on the wire.
• Runt drop (receive): a frame that arrives shorter than 64 bytes is a runt. A conformant switch or NIC discards it and increments a runts (undersize) counter. Runts on a port usually mean a duplex mismatch, a bad cable/transceiver, or a NIC emitting collisions — they are a fault signal, not normal traffic.

Related receive-side error counters worth naming: runts (<64 B, good or bad FCS), giants/oversize (>MTU), CRC/FCS errors (correct length, failed checksum), and fragments (<64 B and bad FCS — the classic collision remnant).

So can you actually send a frame smaller than 64 bytes?

The honest, nuanced verdict — three cases:

Verdict: "By default, no — the NIC pads it to 64 and a compliant switch drops anything shorter as a runt. The 64-byte minimum is a leftover from CSMA/CD collision detection on half-duplex Ethernet; on full-duplex switched links it's no longer needed but kept for compatibility. You can get sub-64-byte frames onto the wire with a cut-through switch mid-forward, or with custom/FPGA hardware — but conformant equipment will treat them as runts and discard them." That answer shows you know the rule, the reason, and the exceptions.

Why traders care: the packets-per-second math

on-wire footprint of a minimum frame:

   64 bytes  frame (DST..FCS)
 +  8 bytes  preamble (7) + SFD (1)
 + 12 bytes  inter-frame gap (IFG)
 ──────────
   84 bytes  =  672 bits  on the wire per minimum-size frame

Why smaller frames = higher packet rate = the real bottleneck. A NIC and its packet-processing pipeline spend a roughly fixed cost per packet (descriptor handling, interrupt/poll, PCIe transaction, hash/parse) largely independent of frame size. Market-data updates and single orders are tiny — often at or near the 64-byte floor — so a firehose of them hits the packet-rate ceiling long before it fills the bandwidth. At 14.88 Mpps you have only ~67.2 ns per packet to receive, parse, and act. That per-packet time budget, not the Gbit/s, is what a low-latency stack is engineered around — see Low-Latency & Trading Networks.

L2 forwarding recap — how a switch moves the frame

A switch is a Layer-2 device: it forwards on the destination MAC, never looking at IP. The core loop:

1. Learn: read the source MAC and record SRC MAC → ingress port in the forwarding database (FDB / MAC address table), implemented in hardware as a CAM for exact-match lookups.
2. Look up: index the FDB/CAM by the destination MAC.
3. Forward or flood: known unicast → send out the single learned port; unknown unicast, broadcast (ff:ff:ff:ff:ff:ff), or multicast → flood to all ports in the VLAN except ingress.

Where the error counters increment: runt / CRC / fragment counters live on the receiving port. A store-and-forward switch increments them and drops the frame before forwarding. A pure cut-through switch may have already forwarded a runt or CRC-error frame by the time it detects the fault; many modern switches therefore run adaptive cut-through — cut-through until a port's error rate climbs, then automatically fall back to store-and-forward to stop propagating corruption.

The opposite end: jumbo frames

If 64 bytes is the floor, jumbo frames are the ceiling above the standard 1500-byte MTU — typically 9000-byte payloads. The trade is the mirror image of the small-frame story: fewer, larger frames mean less per-packet overhead and CPU per byte moved, which helps bulk throughput (storage, backups, replication). They are non-standard, require every device in the path to agree on the MTU (mismatch → drops or fragmentation), and do nothing for — even slightly hurt — the latency-sensitive small-message workloads a trading desk cares about.