Csma Cd - Learning Module

Loading content...

0/228

Minimum Frame Size — The 64-Byte Rule

The Magic Number: 64 Bytes

Every Ethernet frame must be at least 64 bytes long. This isn't an arbitrary design choice—it's a mathematical necessity derived directly from the physics of collision detection.

If a frame is too short, it might finish transmitting before a collision could possibly be detected. The sender would believe the transmission succeeded, while in reality, the frame collided with another and was destroyed. This would break the fundamental guarantee of CSMA/CD: that all collisions are detected.

In this page, we'll derive the 64-byte minimum from first principles, understand what "runt frames" are and why they're problematic, and explore how padding ensures even the smallest payloads meet the minimum requirement.

What You Will Learn

By the end of this page, you will be able to derive the minimum frame size from network parameters, explain why the 64-byte minimum is exactly 512 bits, identify runt frames and understand their implications, and calculate the padding required for any payload size.

Deriving the Minimum Frame Size

The minimum frame size is a direct consequence of the slot time—the maximum time needed to detect a collision. Let's work through the derivation step by step.

The Fundamental Constraint:

For collision detection to work:

Frame Transmission Time ≥ Slot Time

The frame must still be transmitting when collision evidence returns to the sender. If the frame ends earlier, the sender won't know a collision occurred.

Defining Slot Time:

For 10 Mbps Ethernet, the slot time was defined as 512 bit times (51.2 microseconds). This accounts for:

Maximum round-trip propagation delay through 2,500 meters of cable
Delays through repeaters and transceivers
Safety margins for timing variations

From Slot Time to Minimum Frame Size
Step	Calculation	Result
Slot Time Definition	Given for 10 Mbps Ethernet	512 bit times
Convert to Bytes	512 bits ÷ 8 bits/byte	64 bytes
Frame Components	Header(14) + Payload + FCS(4)	Must total ≥ 64 bytes
Minimum Payload	64 - 14 - 4	46 bytes

The Mathematical Derivation:

Let's derive this more rigorously:

Minimum Frame Size = Slot Time (in bits) / 8 bits per byte
                   = 512 bits / 8
                   = 64 bytes

This gives us the minimum frame size at the MAC layer: 64 bytes total, comprising:

Component	Size	Notes
Destination MAC	6 bytes	Recipient's hardware address
Source MAC	6 bytes	Sender's hardware address
Type/Length	2 bytes	EtherType or payload length
Payload	46-1500 bytes	Data from upper layers
FCS (CRC-32)	4 bytes	Frame Check Sequence
Total	64-1518 bytes	Minimum to maximum

The 46-Byte Minimum Payload

The 46-byte minimum payload requirement is often overlooked. When upper-layer protocols (like ARP with only 28 bytes of data) transmit small messages, Ethernet must add padding bytes to reach the 46-byte minimum. This padding is transparent to higher layers but essential for CSMA/CD operation.

Why Exactly 512 Bits?

The 512-bit slot time seems arbitrary until you understand the engineering constraints that produced it. Let's trace the calculation:

Network Geometry Constraints:

Original Ethernet (10BASE5) specified a maximum network diameter of 2,500 meters, achievable through:

Up to 5 cable segments of 500 meters each
Connected by 4 repeaters (following the 5-4-3 rule)

The 5-4-3 rule stated:

5 cable segments maximum
4 repeaters maximum
3 segments can have hosts (others are inter-repeater links)

slot_time_calculation.py
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
# Derivation of Ethernet Slot Time
 
# Physical constants
speed_of_light = 3e8  # m/s
velocity_factor = 0.77  # typical for coaxial cable
propagation_speed = speed_of_light * velocity_factor  # ~2.31e8 m/s
 
# Network geometry (10BASE5 maximum)
max_network_diameter = 2500  # meters
num_repeaters = 4
 
# Calculate one-way propagation delay
cable_propagation_delay = max_network_diameter / propagation_speed
# = 2500 / 2.31e8 = 10.8 microseconds
 
# Repeater delays (each repeater adds delay)
repeater_delay = 0.5e-6  # 0.5 microseconds per repeater
total_repeater_delay = num_repeaters * repeater_delay
# = 4 * 0.5e-6 = 2.0 microseconds
 
# Transceiver delays (at each end)
transceiver_delay = 2 * 1e-6  # 1 microsecond each end
# = 2.0 microseconds
 
# Total one-way delay
one_way_delay = cable_propagation_delay + total_repeater_delay + transceiver_delay
# = 10.8 + 2.0 + 2.0 = 14.8 microseconds
 
# Round-trip time
round_trip_time = 2 * one_way_delay
# = 2 * 14.8 = 29.6 microseconds
 
# Safety margin (jamming, rise times, tolerances)
safety_margin = 1.7  # multiplier
slot_time_microseconds = round_trip_time * safety_margin
# = 29.6 * 1.7 ≈ 50.3 microseconds
 
# Round to convenient value
slot_time_final = 51.2  # microseconds (chosen for binary convenience)
 
# Convert to bit times at 10 Mbps
bit_time = 1 / 10e6  # 100 nanoseconds
slot_time_bits = slot_time_final / (bit_time * 1e6)
# = 51.2 / 0.1 = 512 bit times
 
print(f"Calculated Slot Time: {slot_time_final} μs = {slot_time_bits} bit times")
print(f"Minimum Frame Size: {slot_time_bits / 8} bytes = 64 bytes")

Why 512 Was Chosen:

The actual round-trip time calculation yields approximately 29-30 microseconds, but the final slot time was set to 51.2 microseconds (512 bits) for several practical reasons:

Safety Margins: Component tolerances, temperature variations, and aging effects require headroom.
Jam Signal Time: The 32-bit jam signal must propagate after collision detection.
Binary Convenience: 512 = 2⁹, making hardware implementation simpler with binary counters.
Backward Compatibility: Once established, the slot time became fixed to ensure interoperability.

Power of Two

512 bits = 64 bytes is a power of two (2⁶ bytes), which is computationally elegant for hardware implementation. Binary counters, shift registers, and timing circuits all work more efficiently with power-of-two values.

Frame Structure and Size Requirements

Understanding exactly what counts toward the 64-byte minimum requires a detailed look at Ethernet frame structure.

Complete Ethernet Frame Structure:

Ethernet Frame Components
Field	Size (Bytes)	Counted in 64-Byte Min?	Purpose
Preamble	7	No	Clock synchronization (10101010...)
Start Frame Delimiter	1	No	Signals frame start (10101011)
Destination MAC	6	Yes	Recipient address
Source MAC	6	Yes	Sender address
Type/Length	2	Yes	EtherType or payload length
Payload + Padding	46-1500	Yes	Data from upper layers
FCS (CRC-32)	4	Yes	Error detection
Inter-Frame Gap	12 (96 bits)	No	Mandatory quiet period

Critical Distinction: What's Measured?

The 64-byte minimum applies to the MAC frame only, measured from Destination MAC through FCS. The preamble and SFD are considered physical layer overhead, not part of the frame proper.

┌──────────────────────────────────────────────────────────────────┐
│                    COMPLETE TRANSMISSION                         │
├───────────┬────────────────────────────────────┬─────────────────┤
│ PHYSICAL  │           MAC FRAME (64-1518 bytes)│  PHYSICAL       │
│ OVERHEAD  │                                    │  OVERHEAD       │
├───────────┼──────┬──────┬────┬────────┬────────┼─────────────────┤
│ Preamble  │ Dest │ Src  │Type│Payload │  FCS   │ Inter-Frame Gap │
│ + SFD     │ MAC  │ MAC  │    │+ Pad   │        │                 │
│ (8 bytes) │ (6)  │ (6)  │(2) │(46-1500)│ (4)   │ (12 bytes)      │
└───────────┴──────┴──────┴────┴────────┴────────┴─────────────────┘
                     └───── Must be ≥ 64 bytes ─────┘

Frame Size Calculations

•Minimum MAC Frame: 14 (header) + 46 (min payload) + 4 (FCS) = 64 bytes
•Maximum MAC Frame: 14 (header) + 1500 (max payload) + 4 (FCS) = 1518 bytes
•Total Wire Size (min): 8 (preamble+SFD) + 64 (frame) = 72 bytes
•Total Wire Size (max): 8 (preamble+SFD) + 1518 (frame) = 1526 bytes
•Plus IFG: Add 12 bytes of quiet time between frames

Jumbo Frames

Modern networks often support 'jumbo frames' with payloads up to 9000 bytes. These are not part of the IEEE 802.3 standard but are widely implemented for improved efficiency in high-speed networks. The minimum size requirement (64 bytes) remains unchanged even for jumbo frame support.

Padding Short Payloads

When upper-layer protocols generate payloads smaller than 46 bytes, Ethernet must add padding to meet the minimum frame size requirement. This padding mechanism is transparent to the receiving application.

How Padding Works:

Upper layer submits data to Ethernet (e.g., 28-byte ARP request)
Ethernet calculates required frame size: 14 + 28 + 4 = 46 bytes
46 < 64, so padding is required
Padding bytes added: 64 - 46 = 18 bytes
Final frame: 14 (header) + 28 (data) + 18 (padding) + 4 (FCS) = 64 bytes

padding_calculation.ts
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
// Ethernet Frame Padding Calculator
 
interface FrameComponents {
    headerSize: number;      // 14 bytes (fixed)
    payloadSize: number;     // Variable (from upper layer)
    fcsSize: number;         // 4 bytes (fixed)
    paddingRequired: number; // Calculated
    totalFrameSize: number;  // Final size
}
 
function calculateFramePadding(payloadSize: number): FrameComponents {
    const HEADER_SIZE = 14;      // Dest MAC (6) + Src MAC (6) + Type (2)
    const FCS_SIZE = 4;          // CRC-32
    const MIN_FRAME_SIZE = 64;   // Minimum MAC frame size
    const MIN_PAYLOAD_SIZE = 46; // Minimum data + padding
    
    // Calculate frame without padding
    const frameSizeWithoutPadding = HEADER_SIZE + payloadSize + FCS_SIZE;
    
    // Determine if padding is needed
    let paddingRequired = 0;
    if (frameSizeWithoutPadding < MIN_FRAME_SIZE) {
        paddingRequired = MIN_PAYLOAD_SIZE - payloadSize;
    }
    
    // Calculate total frame size
    const totalFrameSize = Math.max(frameSizeWithoutPadding, MIN_FRAME_SIZE);
    
    return {
        headerSize: HEADER_SIZE,
        payloadSize,
        fcsSize: FCS_SIZE,
        paddingRequired,
        totalFrameSize,
    };
}
 
// Example calculations
console.log("ARP Request (28 bytes):", calculateFramePadding(28));
// Output: { paddingRequired: 18, totalFrameSize: 64 }
 
console.log("ICMP Echo (64 bytes):", calculateFramePadding(64));
// Output: { paddingRequired: 0, totalFrameSize: 82 }
 
console.log("TCP SYN (~40 bytes):", calculateFramePadding(40));
// Output: { paddingRequired: 6, totalFrameSize: 64 }
 
console.log("Large HTTP response (1400 bytes):", calculateFramePadding(1400));
// Output: { paddingRequired: 0, totalFrameSize: 1418 }

Common Protocols and Their Padding Requirements
Protocol	Typical Payload	Padding Needed	Final Frame Size
ARP Request/Reply	28 bytes	18 bytes	64 bytes
ICMP Echo (small)	8 bytes	38 bytes	64 bytes
DHCP Discover	~300 bytes	None	~318 bytes
DNS Query	~40-60 bytes	0-6 bytes	64-78 bytes
TCP SYN	~40 bytes	6 bytes	64 bytes
TCP ACK (no data)	~40 bytes	6 bytes	64 bytes
VoIP RTP Packet	~20 bytes	26 bytes	64 bytes

Padding Content:

The IEEE 802.3 standard does not specify what bytes should be used for padding. Common implementations use:

Zero bytes (0x00): Most common approach
Random bytes: Some implementations for security
Undefined: The standard allows any content

Distinguishing Data from Padding:

A potential question: How does the receiver know where the payload ends and padding begins? The answer depends on the Type/Length field:

If Type/Length ≤ 1500: The field indicates payload length. Receiver knows exactly where data ends.
If Type/Length ≥ 1536 (0x0600): The field is an EtherType. The upper-layer protocol must include its own length information.

For example, when Type/Length = 0x0800 (IPv4), the IP header contains a "Total Length" field that specifies the exact size of the IP packet, allowing the receiver to ignore any trailing padding bytes.

Security Implications

Padding bytes can leak information if not properly handled. Some systems inadvertently include memory contents as padding ('pad leaking'). This has led to security vulnerabilities where sensitive data was exposed in Ethernet frames. Properly zeroing padding bytes is a security best practice.

Runt Frames: When Minimums Are Violated

Frames smaller than 64 bytes are called runt frames (or runts). They indicate network problems and are automatically discarded by receivers.

What Causes Runt Frames?

Runt frames typically result from:

Collisions: When a collision occurs, the transmitter aborts mid-frame, leaving a truncated fragment on the wire.
Hardware Failures: Malfunctioning NICs may transmit incomplete frames.
Software Bugs: Poorly implemented drivers might not enforce minimum size.
Cable Problems: Signal degradation may corrupt frame length detection.

Runt Frame Characteristics

•Size: < 64 bytes
•FCS: Often invalid or missing
•Cause: Usually collisions
•Action: Always discarded
•Impact: No data loss (will be retransmitted)

Valid Frame Characteristics

•Size: 64-1518 bytes
•FCS: Valid CRC-32
•Format: Proper header structure
•Action: Processed normally
•Impact: Data delivered to upper layer

Collision Fragments:

The most common source of runt frames is collision fragments. When two stations collide:

Both detect the collision (via CSMA/CD)
Both stop transmitting immediately
Both transmit a jam signal (32 bits)
The combined frame fragments are less than 64 bytes

Normal Transmission:
┌────────────────────────────────────────────────────────────┐
│ Preamble │ Header │    Payload (46-1500 bytes)    │  FCS  │
└────────────────────────────────────────────────────────────┘
                     ≥ 64 bytes (MAC frame)

Collision Fragment (Runt):
┌───────────────────────────┐
│ Preamble │ Header │ Part..│  ← Transmission aborted
└───────────────────────────┘
                     < 64 bytes → DISCARDED

Frame Classification by Size
Classification	Size Range	Valid FCS?	Likely Cause
Runt Frame	< 64 bytes	Usually No	Collision, hardware failure
Valid Frame	64-1518 bytes	Yes	Normal operation
Baby Giant	1519-1522 bytes	Yes	VLAN tagging (802.1Q)
Jumbo Frame	1519-9000+ bytes	Yes	Jumbo frame support
Giant Frame	1518 bytes	Often No	Configuration error, jabber

Monitoring Runts

A high runt frame count on a switch port is a strong indicator of collision problems (likely a half-duplex mismatch) or hardware issues. Network monitoring tools track runt statistics as key health indicators. In modern full-duplex networks, runts should be extremely rare—their presence warrants investigation.

Minimum Frame Size at Higher Speeds

As Ethernet speeds increased beyond 10 Mbps, the minimum frame size requirement created interesting challenges. The fundamental problem: faster bit rates mean frames transmit in less time, but propagation delay stays the same.

The Scaling Problem:

At 10 Mbps:

64 bytes = 512 bits = 51.2 μs transmission time
Maximum network diameter: ~2500 m

At 100 Mbps (10× faster):

64 bytes = 512 bits = 5.12 μs transmission time
Maximum network diameter: ~250 m (10× shorter!)

At 1 Gbps (100× faster):

64 bytes = 512 bits = 0.512 μs (512 ns) transmission time
Maximum network diameter: ~25 m (impractical!)

Minimum Frame Size vs. Speed Trade-offs
Speed	Bit Time	64-Byte TX Time	Theoretical Max Distance	Solution
10 Mbps	100 ns	51.2 μs	2,500 m	Standard rules apply
100 Mbps	10 ns	5.12 μs	250 m	Reduced distance acceptable
1 Gbps	1 ns	512 ns	25 m	Carrier extension / full-duplex
10 Gbps	0.1 ns	51.2 ns	~2.5 m	Full-duplex only (no CSMA/CD)

Gigabit Ethernet Solutions:

For Gigabit Ethernet (1000BASE-T), maintaining the 64-byte minimum with half-duplex CSMA/CD would limit network diameter to about 25 meters—far too restrictive. Two solutions were developed:

1. Carrier Extension:

Carrier extension pads the transmission (not the frame data) to 512 bytes:

Without Extension (64-byte frame):
┌────────────────────────────────────┐
│ Frame (64 bytes) │
└────────────────────────────────────┘
    512 ns transmission ← Too short for collision detection

With Carrier Extension:
┌────────────────────────────────────────────────────────────────────┐
│ Frame (64 bytes) │          Extension Symbols (448 bytes)         │
└────────────────────────────────────────────────────────────────────┘
    4096 ns (4.096 μs) transmission ← Adequate for ~200 m network

The extension consists of special symbols that extend the carrier but don't add frame data.

2. Frame Bursting:

Frame bursting allows a station to send multiple short frames back-to-back after a single carrier sense:

Frame Bursting (maximum 65,536 bits = 8,192 bytes burst):
┌────────┬────────┬────────┬────────┬────────┐
│ Frame1 │ IFG    │ Frame2 │ IFG    │ Frame3 │...
└────────┴────────┴────────┴────────┴────────┘
          ↑ Extension pad fills to slotTime for first frame

After the first frame (with carrier extension if needed), subsequent frames can be sent with only the inter-frame gap, amortizing the carrier extension overhead.

Modern Reality: Full-Duplex Dominates

In practice, carrier extension and frame bursting are rarely used because virtually all Gigabit and faster Ethernet is deployed in full-duplex mode with switches. Half-duplex Gigabit Ethernet exists in the standard but is almost never implemented. At 10 Gbps and above, half-duplex mode is not even defined—CSMA/CD is completely abandoned.

Practical Implications of Minimum Frame Size

The 64-byte minimum has real-world consequences for network design, protocol efficiency, and application performance.

Protocol Efficiency Impact:

For small messages, the overhead is significant:

Data Size	Frame Size	Overhead	Efficiency
1 byte	64 bytes	63 bytes	1.6%
10 bytes	64 bytes	54 bytes	15.6%
28 bytes (ARP)	64 bytes	36 bytes	43.8%
46 bytes	64 bytes	18 bytes	71.9%
1500 bytes	1518 bytes	18 bytes	98.8%

Applications that frequently send small messages (real-time gaming, VoIP, telemetry) suffer from this overhead.

Design Considerations

•Batching: Combine multiple small messages into one frame to reduce overhead
•Protocol Design: Protocols like TCP can piggyback ACKs on data to avoid minimum-frame ACKs
•Compression: Reduce payload size to fit more data per frame
•Jumbo Frames: Increase maximum frame size to improve large-transfer efficiency
•Network Monitoring: Track runt/giant frame counts as health indicators

Performance Scenario: VoIP Traffic

Voice over IP (VoIP) provides a good case study:

G.711 codec: 20ms of audio = 160 bytes of voice data
RTP header: 12 bytes
UDP header: 8 bytes
IP header: 20 bytes
Total payload: 200 bytes
Ethernet frame: 200 + 14 + 4 = 218 bytes

No padding needed, but consider G.729:

G.729 codec: 20ms of audio = 20 bytes
Headers: 40 bytes
Total payload: 60 bytes
With padding: 64 - (14+4) = 46 bytes min payload
46 - 60 = No padding needed, but only 60 bytes used

If sending even smaller voice samples:

10ms G.729 = 10 bytes
Headers: 40 bytes
Total: 50 bytes payload
Padding needed: 46 - 50 = None, but frame is 64 bytes minimum

The minimum frame size means tiny voice packets require 64 bytes regardless of actual content.

Wireshark Analysis

When capturing packets with Wireshark, you'll see the reported frame length and can calculate padding. Wireshark's 'Frame' layer shows the total captured bytes. For small protocols like ARP, you'll notice the captured frame is always 64 bytes minimum, with zeros filling the padding region.

Summary: The 64-Byte Rule

The minimum frame size is one of Ethernet's fundamental design parameters, directly derived from collision detection requirements.

Key Takeaways

•64 bytes derives from slot time — Frame transmission must last at least as long as the round-trip time for collision detection.
•512 bits = 64 bytes — The slot time of 51.2 μs at 10 Mbps equals 512 bit times.
•Minimum payload is 46 bytes — After 14-byte header and 4-byte FCS, payload must be ≥46 bytes.
•Padding is transparent — Short payloads are padded automatically; receivers use length fields to extract actual data.
•Runt frames indicate problems — Frames <64 bytes result from collisions or faults and are discarded.
•Higher speeds require solutions — Gigabit Ethernet uses carrier extension or full-duplex mode to address timing constraints.

What's Next:

With minimum frame size understood, we turn to what happens immediately after a collision is detected: the jam signal. This special signal ensures all stations recognize that a collision has occurred and must abort their transmissions.

Page Complete

You now understand why Ethernet mandates a 64-byte minimum frame size and how this requirement propagates through network design. Next, we'll examine the jam signal—the mechanism that enforces collision acknowledgment across all transmitting stations.