Diagnosing a Slow Link: Is the Switch Really Faulty?
A campus networking lab runs iperf3 between two hosts on the same 1 Gbps Ethernet path. The measured round-trip time is 20 ms, and the path shows 0.1% random packet loss on a long ping run. Both hosts run a current Linux kernel, but the application socket in use has autotuning disabled and the advertised receive window is fixed at 64 KB. A single TCP stream reaches 22 Mbps. Four parallel streams together reach 61 Mbps. Interface counters show no CRC errors, no runts and no collisions; both ports are full duplex at 1 Gbps; switch CPU utilisation is 40%. The student concludes that the switch is faulty and submits a purchase request for a replacement. The lab supervisor asks you to review the measurement before any purchase is approved.
1. Compute the bandwidth-delay product and the window-limited throughput for this path, and assess whether the measurements support the claim that the switch is faulty.
Read the worked answer
The bandwidth-delay product is the link rate multiplied by the round-trip time: 1,000,000,000 bits per second times 0.020 seconds equals 20,000,000 bits, or 20 Mbit, which is 2.5 MB. That is the amount of data the sender must have in flight to keep the pipe full.
With a fixed 64 KB receive window, the maximum throughput is window divided by RTT: 65,536 bytes times 8, divided by 0.020 seconds, which is 524,288 bits divided by 0.020, or about 26.2 Mbps. The observed 22 Mbps single-stream figure is therefore close to the window limit, not a hardware ceiling. Four streams raise the aggregate to 61 Mbps because each stream carries its own window, so the combined in-flight data increases; this is exactly the pattern expected when the per-connection window, not the switch, is the bottleneck. Clean interface counters and full-duplex operation further argue against a faulty switch. On this evidence the purchase request is not justified; the path is behaving as the end-host configuration predicts.
2. Explain why loss and window size interact here, and recommend the next set of tests before any conclusion is drawn.
Read the worked answer
TCP congestion control treats loss as a congestion signal. With 0.1% random loss, a single stream repeatedly halves its congestion window, and because the fixed 64 KB receive window already caps the flow, the sender often cannot grow back to the window limit before the next loss event. Parallel streams help because loss events are distributed across independent congestion controllers, so aggregate throughput rises even though each stream still suffers. This is a transport-layer effect, not a switching defect.
The next tests should isolate the variables. First, repeat iperf3 with window scaling enabled and a large socket buffer; if throughput rises well above 26 Mbps, the window was the limiter. Second, run a UDP test at a controlled rate to measure loss, jitter and one-way delay independently of TCP. Third, use multiple parallel streams with a fixed total window to separate per-flow from per-path limits. Fourth, run a path trace and check for policers, shaping or a 100 Mbps segment somewhere in the path. Fifth, verify that the loss is random rather than bursty by inspecting the ping sequence numbers. Only after these tests fail to explain the numbers should hardware replacement be considered, and the report should state the configuration under which each measurement was taken.