Exponential Backoff in Ethernet

Binary Exponential Backoff provides an elegant mechanism for collision resolution—stations back off for increasingly long periods, spreading their retransmission attempts across time. But what if, despite this mechanism, a station continues to experience collisions? Should it retry forever?

The answer is definitively no. Ethernet imposes a maximum retry limit of 16 collisions. After experiencing 16 consecutive collisions on a single frame, the station abandons its transmission attempt and reports failure to the upper layer. This limit is not a design flaw—it's a crucial safety mechanism that prevents pathological behavior, bounds worst-case latency, and maintains network health under extreme conditions.

IEEE 802.3 specifies that a station must attempt transmission up to 16 times (one initial transmission plus 15 retries, or equivalently, up to 16 collision events). If all 16 attempts result in collisions, the frame is discarded and the station reports an Excessive Collision Error to the MAC client (typically the network layer).

Official Specification:

attemptLimit = 16

IF collision_count > attemptLimit THEN
    Discard frame
    Report excessiveCollisionError to MAC client
    Reset collision_count to 0
    Proceed to next frame in queue (if any)
END IF

Why 16 Specifically?

The choice of 16 as the maximum retry count balances several factors:

1. Statistical Adequacy: After 16 attempts with a window of 1024 slots, a two-station collision has been given ample opportunity to resolve. The probability of 16 consecutive collisions between two stations is astronomically small under normal conditions.

2. Bounded Worst-Case Delay: 16 retries bounds the maximum time a frame can consume the station's transmission resources. This prevents a single problematic frame from blocking the queue indefinitely.

3. Network Health Signal: Reaching 16 collisions is so improbable under normal operation that it signals severe network problems (faulty equipment, gross misconfiguration, or malicious behavior). Continuing to retry would likely be futile.

4. Historical Consistency: The limit of 16 has been part of Ethernet since the earliest DIX standards and represents decades of practical validation.

Understanding the probability of 16 consecutive collisions reveals why the retry limit is rarely reached in healthy networks—and why reaching it is a red flag.

Two-Station Collision Probability:

Consider the simplest case: two stations colliding repeatedly. After each collision n, both select a random value from [0, 2^min(n,10) - 1]. They collide again only if they select the same value.

With More Stations:

As the number of contending stations increases, the probability of extended collision sequences rises:

Note: These are rough approximations. The exact calculations depend on collision patterns and window utilization.

Implication:

If your network experiences excessive collision errors:

1. It's NOT random bad luck
2. Something is causing deterministic collisions (equipment failure, design problem)
3. Investigation is mandatory

When a frame experiences 16 consecutive collisions and is discarded, the Ethernet MAC layer must report this failure to its client—typically the network layer (IP) or a higher-layer protocol. This reporting follows a well-defined interface.

MAC Service Primitive:

The IEEE 802.3 standard defines the interface between the MAC sublayer and its client through service primitives. When excessive collisions occur, the MAC reports:

MA_DATA.confirm (
    destination_address,
    status = EXCESSIVE_COLLISION_ERROR
)

This primitive indicates that the frame addressed to the specified destination could not be delivered due to excessive collisions.

What Higher Layers See:

1. IP Layer: Receives notification that the datagram was not transmitted. IP itself is unreliable and typically does not retry—it simply discards the datagram. The sender is not notified at the IP level.

2. TCP Layer: TCP uses its own acknowledgment mechanism. If an Ethernet frame (carrying a TCP segment) is discarded, TCP will not receive an ACK and will eventually retransmit. TCP handles the loss transparently.

3. UDP Layer: Like IP, UDP provides no reliability. The datagram is simply lost. Applications using UDP must handle potential losses themselves.

4. Application Layer: Unless using reliable transport (TCP), the application may not know the frame was lost until the expected response times out.

Excessive collisions don't occur randomly—they indicate specific network problems. Understanding potential causes helps with rapid diagnosis and resolution.

Hardware Faults:

Network Design Violations:

Software/Configuration Issues:

When excessive collisions occur—even occasionally—they have ripple effects throughout the network and application stack.

Direct Performance Impact:

1. Wasted Bandwidth: Each collision wastes the time spent transmitting partial frames, jam signals, and backoff periods. With 16 collisions:

   • ~16 partial transmissions (up to 64 bytes each = 1024 bytes)
   • ~16 jam signals (4 bytes each = 64 bytes)
   • Average backoff time across attempts ≈ 26 ms total

2. Transmission Delay: The frame that eventually gives up has consumed ~30+ ms of the station's transmit time—time during which other frames queued.

3. Queue Backup: While a station struggles with one problematic frame, its transmit queue grows. After the frame is discarded, the queue must be drained, causing additional delay for subsequent frames.

Indirect Effects:

• TCP Retransmission Delays: When a TCP segment is lost due to excessive collisions, TCP waits for its retransmission timeout (typically 200ms-1s) before resending. This is orders of magnitude longer than the Ethernet-level delay.

• Application Timeouts: Applications may time out waiting for responses that were lost to excessive collisions, causing user-visible failures.

• Congestion Feedback Loops: TCP interprets lost segments as congestion and reduces its sending rate. With chronic excessive collisions, TCP throughput plummets.

• Jitter: Variable collision resolution times introduce jitter (variation in delay), problematic for real-time applications like VoIP or video.

Proactive monitoring for excessive collisions can prevent performance problems from escalating. Various tools and techniques help identify and diagnose collision issues.

NIC Statistics:

Every Ethernet NIC maintains counters for various events. Relevant counters for collision monitoring include:

SNMP Monitoring:

In enterprise environments, SNMP (Simple Network Management Protocol) can poll these counters remotely:

IF-MIB::ifOutErrors        - Total output errors (includes excessive collisions)
EtherLike-MIB::dot3StatsExcessiveCollisions - Excessive collision count
EtherLike-MIB::dot3StatsLateCollisions      - Late collision count  
EtherLike-MIB::dot3StatsSingleCollisionFrames
EtherLike-MIB::dot3StatsMultipleCollisionFrames

Network management systems can alert when these counters exceed thresholds.

Diagnostic Checklist:

When excessive collisions are detected:

The 16-retry limit has remained unchanged since Ethernet's earliest days. Understanding this persistence reveals how well the original design decisions hold up.

Original DIX Specification (1980):

The Digital-Intel-Xerox (DIX) Ethernet specification set the retry limit at 16, choosing a power of 2 for implementation convenience. The designers recognized:

1. The limit must be high enough to handle normal congestion
2. The limit must be low enough to bound worst-case behavior
3. The probability of reaching the limit randomly should be negligible

16 satisfied all three criteria with margin to spare.

Why Has It Never Changed?

1. It Works: Decades of deployment have proven 16 is the right number. No compelling reason to change emerged.

2. Interoperability: Changing the limit would create compatibility issues between old and new equipment.

3. Irrelevance in Modern Networks: With switches eliminating collisions, the exact retry limit matters less. Even if changed, most devices never experience any collisions.

4. Conservative Engineering: Network standards favor stability. Without clear evidence of a problem, the standard body won't change a working parameter.

Contrast with Other Parameters:

Unlike the retry limit, other Ethernet parameters have evolved:

• Speed: 10 Mbps → 100 Mbps → 1 Gbps → 10 Gbps → 100 Gbps → 400 Gbps
• Frame size: Extended with jumbo frames (9000 bytes)
• Slot time: Adjusted for different speeds

The retry limit's stability amid these changes demonstrates it was correctly specified from the beginning.

We've comprehensively examined the maximum retry limit in Binary Exponential Backoff. Let's consolidate the essential understanding:

What's Next:

The final page of this module examines fairness considerations—how BEB affects different stations' chances of successful transmission, potential fairness issues, and how the protocol balances efficiency with equitable access.