Delay, Loss, and Throughput in Packet Networks

When a packet travels from a source to a destination, it passes through a sequence of routers, and at each router (and at the sending host) it experiences four distinct delays before crossing the outgoing link. Processing delay (`d_proc`) is the time a router spends examining the packet header, checking for bit errors, and determining the outgoing link — typically microseconds on modern hardware. Queuing delay (`d_queue`) is the time the packet waits in a buffer while other packets ahead of it are transmitted; it depends on router load and can range from zero to milliseconds or, under congestion, seconds. Transmission delay (`d_trans`) is the time required to push all of the packet's bits onto the link, equal to packet length `L` divided by link transmission rate `R`. Propagation delay (`d_prop`) is the time for a bit to physically travel across the link, equal to physical link length `d` divided by the propagation speed of the medium `s` (roughly `2×10^8` m/s in copper or fiber, close to the speed of light). These four terms sum to the nodal delay at one router: ``` d_nodal = d_proc + d_queue + d_trans + d_prop ``` A common source of confusion is transmission delay versus propagation delay: transmission delay is about link rate (how fast bits get pushed out), while propagation delay is about link length (how long a bit takes to travel once it is on the wire). A satellite link can have tiny transmission delay (high bandwidth) but huge propagation delay (36,000 km up and down), while a short Ethernet cable has the opposite profile.

Queuing delay is the most variable and most interesting term because it depends on statistics of arriving traffic, not just fixed physical properties. Define traffic intensity as ``` ρ = (L · a) / R ``` where `a` is the average packet arrival rate (packets/sec), `L` is average packet length (bits), and `R` is the link's transmission rate (bits/sec). The product `L·a` is the average bit-arrival rate; dividing by `R` gives the fraction of link capacity being demanded. If `ρ > 1`, the queue grows without bound (more work arrives than the link can ever clear); if `ρ` is close to but below 1, average queuing delay grows very large due to bursts in arrivals; if `ρ` is small, queuing delay is small and stable. When a router's buffer is finite (as all real buffers are) and a packet arrives to find the buffer full, that packet is dropped — this is packet loss. Loss is a separate performance axis from delay: a network with abundant loss but low delay, or vice versa, is possible, and different applications (real-time voice vs. bulk file transfer) tolerate these differently. Finally, throughput is the rate, in bits/sec, at which data is successfully delivered from sender to receiver; for a single flow traversing a path of links, instantaneous throughput is capped by the bottleneck link, defined as the link along the path with the smallest transmission rate.

Step 1 — Model one router as a queueing system. Each router output port is a server with service rate `R` (bits/sec) preceded by a finite buffer. Packets arrive, wait in the buffer (queuing delay), then are transmitted (transmission delay) after minimal processing (processing delay). This maps directly onto standard queueing-theory abstractions (arrival process, service process, buffer capacity).

Step 2 — Compute per-hop delay components. For a link of rate `R` bits/sec and packet size `L` bits: ``` d_trans = L / R ``` For a link of physical length `d` meters and propagation speed `s` meters/sec: ``` d_prop = d / s ``` `d_proc` is typically a small, roughly constant value determined by router hardware (order of microseconds or less for modern ASIC-based routers). `d_queue` must be estimated statistically or measured; it is not a closed-form function of `L, R, d` alone — it depends on the arrival pattern of other traffic.

Step 3 — Reason about queuing delay qualitatively (and semi-quantitatively). Using a simplified model where packets arrive periodically with average intensity `ρ = La/R`:

• If `ρ ≈ 0`: almost no queuing delay — packets rarely find another packet in service.
• If `ρ → 1`: average queuing delay → ∞ in the idealized infinite-buffer model, because the router's throughput capacity is fully saturated and any burstiness accumulates unboundedly.
• If `ρ > 1`: the queue is unstable — arrivals permanently outpace service, so with a finite buffer, loss becomes inevitable and frequent.

A commonly used closed-form approximation (from queueing theory, e.g., M/M/1) for average queuing delay is: ``` d_queue ≈ (ρ / (1 − ρ)) · d_trans for 0 ≤ ρ < 1 ``` This captures the qualitative blow-up as `ρ → 1` even though real router traffic is rarely perfectly Markovian.

Step 4 — Sum delays across the whole path. For a path of `N` links (routers `R_1, …, R_N` plus the final hop to the destination), total end-to-end delay is the sum of nodal delays at each hop: ``` d_end-to-end = Σ_{i=1}^{N} (d_proc,i + d_queue,i + d_trans,i + d_prop,i) ``` This is a straightforward sum because delay components are experienced sequentially as the packet physically moves along the path — there is no overlap to exploit at a single-packet level (though pipelining across multiple packets does overlap transmission and propagation of different packets, which is why throughput analysis is separate from single-packet delay analysis).

Step 5 — Determine throughput as bottleneck-limited. For a single flow with no competing traffic, traversing links of rates `R_1, R_2, …, R_N`, the maximum achievable end-to-end throughput is: ``` throughput = min(R_1, R_2, …, R_N) ``` because no link can forward data faster than its own transmission rate, and every bit must cross every link in sequence. In the presence of competing flows sharing a link, each flow's effective throughput is further reduced, often modeled by fair-sharing (e.g., each of `k` flows sharing a link of rate `R` gets roughly `R/k` under max-min fairness), though this depends on the transport protocol's congestion-control behavior.

Step 6 — Model loss via finite buffers. A router's buffer holds at most `B` bits (or `B_pkt` packets). If a packet of size `L` arrives when the current buffer occupancy plus `L` exceeds `B`, the packet is dropped (in the simplest tail-drop policy). The long-run packet loss rate is the fraction of arriving packets dropped due to buffer overflow — this rises sharply as `ρ` approaches or exceeds 1, because a saturated server cannot drain the queue fast enough to make room for bursts. ```pseudocode // Simulated router output-queue model (discrete-event, tail-drop) // Inputs: arrival_times[], packet_lengths[], R (bits/sec), B (buffer capacity in bits) // Outputs: per-packet delay, count of dropped packets, achieved throughput function SIMULATE_QUEUE(arrival_times, packet_lengths, R, B): queue_occupancy_bits = 0 // current buffer contents server_free_at = 0.0 // time link becomes free departures = [] // (packet_id, departure_time) dropped = 0 bits_delivered = 0 n = length(arrival_times) for i in 0 .. n-1: t_arrive = arrival_times[i] L = packet_lengths[i] // Remove packets that have already finished transmitting by t_arrive // (in an event-driven sim this is handled by processing departure events; // here we track occupancy via server_free_at as a proxy for FIFO draining) effective_occupancy = max(0, queue_occupancy_bits - (t_arrive relative drain)) if effective_occupancy + L > B: dropped += 1 continue // tail-drop: packet is lost, not queued // Packet is accepted into the buffer start_service = max(t_arrive, server_free_at) d_trans = L / R finish_time = start_service + d_trans server_free_at = finish_time queue_occupancy_bits = effective_occupancy + L // once transmitted, its bits leave the buffer (handled by drain accounting) d_queue = start_service - t_arrive departures.append((i, finish_time, d_queue)) bits_delivered += L total_time = departures[-1].finish_time - arrival_times[0] throughput = bits_delivered / total_time loss_rate = dropped / n return departures, dropped, loss_rate, throughput ``` The pseudocode is intentionally close to a real event-driven simulator: it tracks buffer occupancy, applies tail-drop when the incoming packet would overflow `B`, and computes per-packet queuing delay as `start_service − t_arrive`. In a production simulator, `effective_occupancy` would be computed exactly by maintaining a departure-event priority queue rather than the informal proxy shown; the structure of accept/drop/serve logic, however, is exactly what real router queue management implements.

Per-packet delay computation is `O(1)` per packet: computing `d_trans = L/R` and `d_prop = d/s` are constant-time arithmetic operations, and `d_proc` is a fixed hardware constant. Summing delay across a path of `N` hops is `O(N)`, since it is a single pass accumulating four terms per hop — there is no way to do better than examining every hop once, because each hop contributes independently to total latency and none can be skipped without losing information about the path's actual delay.

Simulating the queue (the pseudocode above) processes `n` arriving packets, and with a well-implemented event-driven core (a priority queue for departure events), the whole simulation runs in `O(n log n)` time — `O(log n)` for each priority-queue insertion/extraction, done `O(n)` times — and `O(B)` or `O(n)` space depending on whether buffer occupancy is tracked in bits or as a list of currently-buffered packets. This is efficient and exactly what real network simulators (e.g., ns-3, OMNeT++) do at the packet level.

Correctness of the delay decomposition follows directly from the physical process a packet undergoes: it cannot begin being examined until it arrives (`d_proc` starts at arrival), it cannot begin transmission until processing is done and the link is free (`d_queue` is exactly the extra wait beyond `d_proc` caused by link contention), it cannot finish crossing the link until all its bits are pushed out (`d_trans` is deterministic given `L, R`), and the first bit cannot reach the next router until it has physically traveled the link (`d_prop` is deterministic given `d, s`). These four intervals are disjoint and exhaustive by construction — every packet undergoes exactly this ordered sequence at each hop — so their sum is provably equal to the nodal delay; there is no hidden fifth component and no double-counting, since queuing delay is defined as time-in-buffer specifically excluding the processing and transmission intervals.

Correctness of the bottleneck-throughput claim rests on a simple invariant: consider a single flow with no cross-traffic sending across links of rates `R_1, …, R_N` in series. Because bits must cross every link in order, and link `i` can accept new bits no faster than `R_i`, the sustained rate at which bits emerge at the destination cannot exceed `R_i` for any `i` — otherwise link `i` would be asked to carry more bits per second than its physical rate permits, a contradiction. Hence sustainable throughput ≤ `min_i R_i`. That this bound is achievable (not just an upper bound) follows because a sender can pace transmissions at exactly `min_i R_i` and, with sufficiently large buffers at intermediate hops to absorb rate mismatches, every link operates at its own maximum utilization without loss — achieving the bound in steady state.

Honest tradeoffs. The M/M/1-style formula `d_queue ≈ ρ/(1−ρ) · d_trans` is an idealization assuming Poisson arrivals and exponential service times; real router traffic is bursty and self-similar, so actual queuing delay is often worse than this formula predicts at moderate `ρ`, and buffer-sizing rules of thumb (like the old "bandwidth-delay product" buffer rule) have been revised in modern research (e.g., "sizing router buffers" literature) precisely because the classical model understates burst-driven overflow. Likewise, larger buffers reduce loss but increase worst-case queuing delay — this is the celebrated bufferbloat problem, a direct real-world consequence of the delay/loss tradeoff this article formalizes.

Consider a packet traveling from a home laptop to a cloud server across three hops: a home Wi-Fi/router hop, an ISP access-network hop, and a data-center ingress hop. Suppose the packet is `L = 12,000` bits (1500 bytes, typical Ethernet MTU), and we're given per-hop parameters:

Step 1 — Transmission delay per hop (`d_trans = L/R`):

• Hop 1: `12,000 / (100×10⁶) = 120 μs`
• Hop 2: `12,000 / (20×10⁶) = 600 μs`
• Hop 3: `12,000 / (10×10⁹) = 1.2 μs`

Step 2 — Propagation delay per hop (`d_prop = d/s`):

• Hop 1: `5 / (2×10⁸) = 0.025 μs`
• Hop 2: `15,000 / (2×10⁸) = 75 μs`
• Hop 3: `800,000 / (2×10⁸) = 4,000 μs (= 4 ms)`

Step 3 — Queuing delay per hop using `d_queue ≈ (ρ/(1−ρ)) · d_trans`:

• Hop 1: `ρ=0.10` → `(0.10/0.90) × 120 = 13.3 μs`
• Hop 2: `ρ=0.70` → `(0.70/0.30) × 600 = 1400 μs`
• Hop 3: `ρ=0.30` → `(0.30/0.70) × 1.2 = 0.51 μs`

Step 4 — Nodal delay per hop:

Step 5 — Total end-to-end delay: ``` d_end-to-end = 135.3 + 2080 + 4002.7 = 6218 μs ≈ 6.22 ms ``` Notice the striking asymmetry: hop 2 is dominated by queuing delay (its `ρ=0.70` is close to saturation on a modest 20 Mbps link), while hop 3 is dominated overwhelmingly by propagation delay (800 km at light-speed-in-fiber, regardless of its enormous 10 Gbps capacity). This is exactly why a high-bandwidth transcontinental link can still feel "laggy" — bandwidth and latency are governed by different physics — while a congested but short home-ISP hop can dominate total delay through queuing alone.

Step 6 — Throughput. For a single flow with no competing traffic across this path: ``` throughput = min(100 Mbps, 20 Mbps, 10 Gbps) = 20 Mbps ``` Hop 2 is the bottleneck link. Even though hop 3 offers 10 Gbps, the flow can never sustain more than 20 Mbps end-to-end, because every bit must first squeeze through the 20 Mbps hop. This matches everyday experience: a fast data-center network and a fast home Ethernet port cannot overcome a slow last-mile or ISP-peering link.

Step 7 — Loss under bursts. Suppose hop 2's buffer holds `B = 100,000` bits (about 8.3 packets of this size). If a burst of 12 packets (144,000 bits) arrives back-to-back while `ρ=0.70` traffic is already partially occupying the buffer, several trailing packets in the burst will find the buffer full and be tail-dropped — illustrating that loss is a distinct, burst-triggered event layered on top of the average-case queuing delay computed above.

The mathematics underlying queuing delay predates computer networks entirely, originating in early 20th-century telephony engineering, and was later adapted wholesale to packet-switched networks by the architects of the ARPANET and its successors.

Every modern network protocol and application is shaped by the delay/loss/throughput tradeoffs described here. TCP congestion control algorithms directly measure round-trip time (dominated by queuing and propagation delay) and packet loss to infer network congestion and adjust sending rate — the entire design of protocols like TCP Reno, CUBIC, and BBR is an engineering response to exactly the phenomena modeled above. Content delivery networks (CDNs) like Cloudflare and Akamai exist specifically to reduce propagation delay by placing servers physically closer to users, since no amount of bandwidth upgrade can shrink speed-of-light latency across continents. Video streaming services (YouTube, Netflix) use adaptive bitrate algorithms that estimate available throughput in real time — precisely the bottleneck-link throughput this article defines — to choose video quality without stalling. Voice-over-IP and real-time gaming are exquisitely sensitive to queuing delay variance (jitter), which is why techniques like Active Queue Management (AQM, e.g., CoDel) were developed to directly combat bufferbloat by intentionally dropping or marking packets before buffers fill completely. Data-center network design obsesses over minimizing all four delay components simultaneously, since even microsecond-scale processing and queuing delays matter at the scale of distributed systems performing millions of requests per second. Understanding this article's four-part delay decomposition and the bottleneck-throughput principle is the essential prerequisite for reasoning correctly about Physical Layer Fundamentals (which determines `R` and `s`) and Multiple Access Protocols (which determines how contention for a shared link creates queuing delay in the first place).

Ask the tutor: How do active queue management schemes like CoDel actually decide when to drop packets before the buffer fills, and how does that change the delay/loss tradeoff?