Routing Metrics

Bandwidth tells us how fast data can flow through a pipe, but it reveals nothing about how long that data takes to arrive. A 10 Gbps transcontinental fiber link and a 10 Gbps local data center connection have identical bandwidth—yet the user experience differs dramatically. The difference is delay.

Delay (also called latency) measures the time required for data to travel from source to destination. For real-time applications like voice, video conferencing, online gaming, and financial trading, delay often matters more than raw bandwidth. A video call on a 10 Mbps connection with 20ms delay will feel instantaneous, while the same call on 1 Gbps with 500ms delay becomes an exercise in frustration.

Total end-to-end delay is not a single phenomenon but a composition of four distinct delay types. Understanding each component is essential for network design, troubleshooting, and routing metric configuration.

Total Delay Formula:

Total Delay = Propagation + Transmission + Queuing + Processing

For a path with n hops:
Total Delay = Σ(Propagation[i] + Transmission[i] + Queuing[i] + Processing[i])
where i = 1 to n

Let's examine each component in detail:

Propagation delay represents a fundamental physical limit that no amount of bandwidth or router upgrades can overcome. Understanding this helps set realistic expectations for network performance, especially for geographically distributed systems.

Why Propagation Delay Cannot Be Reduced:

Propagation delay is constrained by the speed of light—a fundamental physical constant. Even with theoretical improvements:

1. Perfect vacuum fiber: Would only improve from 0.67c to 1.0c (49% improvement at best)
2. Straight-line paths: Real-world cables follow terrain, ocean floors, and rights-of-way, adding 30-50% to straight-line distance
3. No workarounds: Unlike bandwidth or processing, you cannot 'upgrade' propagation delay

Implications for Global Systems:

Transmission delay (also called serialization delay) is the time required to push all bits of a packet onto the transmission medium. Unlike propagation delay, transmission delay can be reduced by increasing bandwidth.

Store-and-Forward Impact:

At each hop, a router must receive the entire packet before forwarding it (store-and-forward switching). This means transmission delay is incurred at every hop:

Total Transmission Delay = Packet Size × Number of Links / Bandwidth

For a 1,500-byte packet over 10 Gbps links with 5 hops:
= 12,000 bits × 5 / 10,000,000,000 bps
= 6 microseconds total

For the same packet over 1 Mbps links with 5 hops:
= 12,000 bits × 5 / 1,000,000 bps
= 60 milliseconds total

The 10,000× difference in transmission delay explains why bandwidth was historically so important for interactive applications, and why modern high-speed networks largely eliminate transmission delay as a concern.

Of the four delay components, queuing delay is uniquely variable—it can range from zero (empty queues) to unbounded (during severe congestion). This variability makes queuing delay both the most impactful and the hardest to predict or incorporate into routing metrics.

The Queuing Model:

When multiple input interfaces want to send traffic through the same output interface, packets queue up waiting for transmission. The queuing delay depends on:

1. Arrival Rate (λ): How fast packets arrive at the queue
2. Service Rate (μ): How fast the output link can send packets (bandwidth)
3. Queue Discipline: FIFO, Priority Queuing, Weighted Fair Queuing, etc.
4. Buffer Size: How many packets can wait before drops occur

Why Routing Protocols Avoid Dynamic Delay:

Given queuing delay's variability, one might expect routing protocols to measure and react to actual delays. However, most protocols use STATIC delay values rather than real-time measurements. Here's why:

1. Routing Instability: If routes changed based on current congestion, traffic would shift to the less-congested path, which would then become congested, causing traffic to shift back—creating oscillations.

2. Measurement Overhead: Continuously measuring delay consumes bandwidth and router resources.

3. Convergence Time: By the time measurements propagate and routes converge, the congestion pattern may have changed.

4. Self-Fulfilling Prophecy: Announcing delay increases can cause traffic to shift away, reducing delay, causing traffic to return—unstable feedback loops.

Early ARPANET experiments with dynamic delay metrics demonstrated these problems dramatically, leading to the adoption of static metrics in production protocols.

EIGRP (Enhanced Interior Gateway Routing Protocol) is notable for explicitly incorporating delay into its composite metric. Understanding EIGRP's delay handling provides insight into practical delay metric implementation.

Key EIGRP Delay Characteristics:

1. Cumulative Summation Unlike bandwidth (which uses the minimum/bottleneck value), EIGRP sums delays across all links in the path. This accurately reflects reality—each link adds to total delay.

2. Static Configuration EIGRP uses statically configured delay values, not measured delays. These defaults approximate typical physical characteristics but can be overridden.

3. Delay Tuning for Traffic Engineering Administrators can modify delay values to influence path selection:

Why Delay and Bandwidth Together?

EIGRP's combination of bandwidth and delay provides more nuanced path selection:

This composite approach captures the trade-offs that network engineers intuitively understand: sometimes you accept lower bandwidth for lower latency (real-time applications), and sometimes you accept higher latency for higher bandwidth (bulk transfers).

Unlike EIGRP, OSPF does not natively incorporate delay into its cost calculation. OSPF cost is based purely on bandwidth (Reference BW / Interface BW). However, network engineers can approximate delay-awareness through manual cost configuration.

The OSPF Delay Problem:

Consider two paths from A to B:

1. Path 1: 10 Gbps local fiber (cost 1, 1ms delay)
2. Path 2: 10 Gbps satellite link (cost 1, 500ms delay)

OSPF sees both paths as identical (cost 1) because bandwidth is identical. With equal costs, OSPF may even load-balance between them—sending half your traffic through a 500ms delay path!

Manual Delay Compensation:

Administrators can manually increase costs on high-delay links:

Delay-Aware OSPF Extensions:

Recognizing OSPF's limitations, several extensions have been developed:

1. OSPF-TE (Traffic Engineering) OSPF-TE extensions (RFC 3630) allow advertising additional link attributes including delay, but these are primarily used by MPLS-TE for constraint-based routing rather than native OSPF path selection.

2. Performance-Based Routing Some vendor implementations (like Cisco's Performance Routing - PfR) overlay performance measurements on top of IGP routing, allowing delay-aware path selection without modifying OSPF itself.

3. Segment Routing Segment Routing can use Flex-Algo to define computation constraints including delay, enabling delay-optimized paths while maintaining OSPF as the underlying protocol.

4. SD-WAN Software-Defined WAN solutions typically measure real-time latency and select paths accordingly, operating above the IGP layer.

While routing protocols use static delay values, network operations require accurate delay measurement for capacity planning, troubleshooting, and SLA verification. Understanding measurement techniques is essential for network engineers.

One-Way vs Round-Trip Delay:

Most measurement tools report Round-Trip Time (RTT), which includes delay in both directions:

RTT = Forward Delay + Reverse Delay

If paths are symmetric: One-Way Delay ≈ RTT / 2
If paths are asymmetric: One-Way Delay ≠ RTT / 2

Asymmetric routing is common in the Internet, making RTT/2 an approximation at best. For precise one-way delay measurement, synchronized clocks (GPS, PTP) are required at both endpoints.

Delay Variation (Jitter):

Beyond absolute delay, delay variation (jitter) significantly impacts real-time applications:

Jitter = |Delay(packet n) - Delay(packet n-1)|

For voice/video:
- < 30ms jitter: Excellent
- 30-50ms jitter: Good
- > 50ms jitter: May cause quality issues

High jitter requires larger receive buffers, which add to end-to-end delay. This creates a trade-off between jitter tolerance and total delay.

We've thoroughly explored delay as a fundamental yet often underappreciated routing metric—from its physical components through protocol implementations and measurement techniques. Let's consolidate the essential knowledge:

Looking Ahead:

Delay captures time, but not quality. A link might have low delay but frequent errors requiring retransmissions. In the next page, we'll explore reliability as a routing metric—how protocols account for link stability, error rates, and the probability of successful packet delivery.

Together, bandwidth, delay, and reliability form the foundation for the composite metrics that modern protocols use to make nuanced routing decisions.