Throughput Calculation

Throughput is the ultimate measure of network utility—how much data actually flows from source to destination per unit time. While bandwidth represents the theoretical maximum capacity, throughput reflects what users actually experience. The gap between the two reveals inefficiencies, bottlenecks, and design limitations.

Why throughput calculations matter: Understanding throughput helps you predict application performance, diagnose bottlenecks, size network infrastructure, and answer interview questions accurately. A network engineer who can calculate expected throughput under various conditions provides immense value to any organization.

These three terms are often confused but have distinct meanings that matter for accurate calculations and clear communication.

Bandwidth (Capacity): The maximum theoretical data rate a link can carry, determined by physical properties and technology. Often stated in Mbps or Gbps.

Throughput: The actual rate at which data is successfully delivered over a path, including all protocol overhead. Always ≤ bandwidth.

Goodput: The rate at which useful application data is delivered, excluding protocol overhead. Always ≤ throughput.

The relationship is: $$Goodput \leq Throughput \leq Bandwidth$$

The Throughput Gap

Several factors reduce throughput below bandwidth:

When a reliable transport protocol (like TCP) uses windowed flow control, the window size can become the limiting factor for throughput.

The Fundamental Relationship

With a sliding window protocol, the maximum throughput is:

$$Throughput_{max} = \frac{Window\ Size}{RTT}$$

This is because:

• The sender can have at most Window Size bytes outstanding (unacknowledged)
• After sending a window's worth, it must wait for ACKs to slide the window
• ACKs arrive after one RTT
• Therefore, at best, one window's worth of data is delivered per RTT

When is Throughput Window-Limited?

Throughput is window-limited when: $$\frac{Window\ Size}{RTT} < Bandwidth$$

Or equivalently, when: $$Window\ Size < Bandwidth \times RTT = BDP$$

The throughput equation becomes:

$$Throughput = \min\left(Bandwidth, \frac{Window}{RTT}\right)$$

If Window ≥ BDP, throughput can reach link bandwidth (assuming no other limits). If Window < BDP, throughput is capped at Window/RTT regardless of link speed.

When packet loss is present, TCP's congestion control limits throughput even if window size is adequate. The Mathis formula (also called the TCP throughput equation) models this relationship:

$$Throughput \approx \frac{MSS}{RTT} \times \frac{C}{\sqrt{p}}$$

Where:

• MSS = Maximum Segment Size (typically 1460 bytes for TCP over Ethernet)
• RTT = Round-trip time
• p = Packet loss probability (as a decimal)
• C = A constant, approximately 1.22 for standard TCP (Reno/NewReno)

This can also be written as:

$$Throughput \approx \frac{1.22 \times MSS}{RTT \times \sqrt{p}}$$

Understanding the Formula

Why 1/√p? TCP's AIMD (Additive Increase, Multiplicative Decrease) congestion control oscillates around an average window size. Analysis shows the average window is proportional to 1/√p. Specifically, the average congestion window in segments is approximately:

$$W_{avg} \approx \frac{1.22}{\sqrt{p}}$$

Why MSS/RTT? Each window delivers W segments of MSS bytes each, and this happens once per RTT. So:

$$Throughput = \frac{W \times MSS}{RTT} = \frac{1.22 \times MSS}{RTT \times \sqrt{p}}$$

Practical Implications

In any multi-link path, the bottleneck link is the link with the minimum bandwidth. It limits the maximum possible throughput for the entire path.

The Bottleneck Principle

$$Throughput_{path} \leq \min(R_1, R_2, \ldots, R_n)$$

No matter how fast other links are, data cannot flow faster than the slowest link allows. This is analogous to water flowing through pipes—the narrowest pipe limits overall flow.

Identifying the Bottleneck

In practice, the bottleneck might not be the lowest-bandwidth link if:

1. Congestion causes queuing at a high-bandwidth link, reducing its effective throughput
2. Window size limits prevent the slow link from actually limiting throughput
3. Processing limits at routers or endpoints become the constraint

Multi-Flow Bottleneck Sharing

When N flows share a bottleneck link with capacity C, each flow gets approximately C/N (under fair queuing). But if flows have different RTTs, shorter-RTT flows tend to grab more bandwidth (RTT unfairness in TCP).

Real throughput calculations must account for protocol overhead at each layer. The effective throughput (goodput) excludes headers:

$$Goodput = Throughput \times \frac{Payload}{Payload + Headers}$$

Or equivalently:

$$Goodput = Throughput \times \eta_{transmission}$$

Where η is the transmission efficiency from the previous section.

Layer-by-Layer Overhead Analysis

For TCP/IP over Ethernet, typical overhead per 1500-byte frame:

Transmission efficiency = 1460 / (1460 + 58) = 96.2%

So for a 1 Gbps link: Goodput ≈ 962 Mbps of actual application data.

When frames or packets are lost and must be retransmitted, effective throughput decreases. The impact depends on the loss probability and the recovery mechanism used.

Retransmission Overhead

With loss probability p and ARQ (Automatic Repeat reQuest):

Average transmissions per packet: $$E[transmissions] = \frac{1}{1-p}$$

Effective throughput: $$Throughput_{effective} = Throughput_{raw} \times (1-p)$$

For example, 10% loss means 1/(1-0.1) = 1.11 transmissions per packet, or 90% of raw throughput.

Go-Back-N vs Selective Repeat

Go-Back-N: When a frame is lost, all subsequent frames are retransmitted. Expected transmissions per frame: $$E_{GBN} = \frac{1 - p + Wp}{1-p}$$

Where W is the window size.

Selective Repeat: Only lost frames are retransmitted. Expected transmissions per frame: $$E_{SR} = \frac{1}{1-p}$$

Selective Repeat is more efficient under loss because Go-Back-N wastes bandwidth retransmitting correctly-received frames.

Different application-layer protocols have vastly different throughput characteristics based on their design and use patterns.

Small Transaction Throughput

For request-response protocols with small messages, throughput is often measured in transactions per second rather than bits per second:

$$TPS = \frac{1}{RTT + Processing\ Time}$$

Or with pipelining (N concurrent requests):

$$TPS = \frac{N}{RTT + Processing\ Time}$$

For example, a database query with 10 ms RTT and 5 ms processing:

• Sequential: 1/(0.01 + 0.005) = 66.7 TPS
• With 10 concurrent connections: 10 × 66.7 = 667 TPS
• With 100 concurrent connections: 1000/0.015 = 6,667 TPS (if server can handle it)