Analysis of TCP Performance Metrics Under Varying Network Traffic Conditions

Introduction

Transmission Control Protocol (TCP) is the backbone of reliable internet communication, handling everything from web browsing to video streaming. Understanding how TCP performs under different network load conditions is critical for network engineers and system administrators. This blog focuses on measuring and analyzing key TCP performance metrics—throughput, goodput, retransmission rate, SACK usage, duplicate ACKs, and out-of-order packets—under three distinct traffic conditions: Normal, Medium, and High. Using hping3 as a traffic generator and Wireshark for packet capture, we observe how TCP congestion control mechanisms respond to increasing network loads and how Selective Acknowledgment (SACK) helps improve reliability.

Objectives

To measure TCP throughput and goodput under Normal, Medium, and High traffic conditions and analyze the gap caused by retransmissions.

To evaluate retransmission behavior and SACK effectiveness across varying load levels, identifying at what traffic threshold retransmission rates spike.

To observe duplicate ACK and out-of-order packet patterns as indicators of network congestion and TCP's fast retransmit/recovery mechanisms in action.

Reference / Source of Inspiration

https://youtu.be/1eJHqyyjHqk?si=UnGXD7u4XKIJpiw4

https://youtu.be/nTQYA432h_k?si=X7Co7imEYl-79Dm_

https://youtu.be/_19UdEtj6Ak?si=4G9SnLiwJyauN4qG

https://youtu.be/hfxM_kriYXc?si=L4rDu-II1laUdLHr

https://youtu.be/HTQLipAG27I?si=aet-KLZEQGaFTdtF

Description:

The Sharkfest presentation on TCP performance analysis demonstrated how real-world traffic captures reveal congestion behavior that theoretical models often miss. This motivated us to generate our own controlled traffic scenarios using hping3 and analyze the resulting PCAPs using Wireshark's statistics and TShark command-line tools.

Architecture:

Diagram Description: The architecture uses a single machine (localhost/127.0.0.1) with two parallel processes. The traffic generator (hping3 running in WSL) sends TCP packets to the localhost destination. Simultaneously, Wireshark captures all loopback interface traffic. The captured packets are then exported as CSV metrics and analyzed using Python to generate comparative graphs across traffic conditions.

Procedure

Common Setup (All Traffic Conditions)

Launch Wireshark and start capture on the loopback interface (lo)

Apply display filter: tcp (to focus only on TCP traffic)

Run the corresponding hping3 command (see below) in WSL terminal

Allow capture to run for sufficient duration (~20,000 packets per condition)

Stop capture, save PCAP, and export statistics as CSV

Normal Traffic Condition (No Additional Load)

No external traffic generation command was executed. Only system background traffic and the Wireshark capture probe itself were active on the loopback interface. This establishes the baseline for TCP behavior without artificial load.

Description: Baseline traffic with no additional load generator running. Only system background traffic and the measurement probe itself.

Output captured: cnda2_all_metrics.csv

Medium / Low-Medium Traffic Condition

Command used:

sudo hping3 -S -p 80 -c 10000 --fast 127.0.0.1

Breakdown:

-S : SYN flag (initiates TCP connection)

-p 80 : Destination port 80 (HTTP)

-c 10000 : Send 10,000 packets

--fast : Send packets at 10 packets/second (moderate rate)

127.0.0.1 : Localhost destination

Description: This command sends 10,000 TCP SYN packets to localhost port 80 at a rate of 10 packets per second. This creates moderate network load without overwhelming TCP's congestion control mechanisms.

Output captured: mid traffic da2_all_metricmidtraffic.csv

High Traffic Condition

Command used:

sudo hping3 -S -p 80 -c 50000 --faster 127.0.0.1

Breakdown:

-S : SYN flag (initiates TCP connection)

-p 80 : Destination port 80 (HTTP)

-c 50000 : Send 50,000 packets

--faster : Send packets at 100 packets/second (high rate)

127.0.0.1 : Localhost destination

Description: This command sends 50,000 TCP SYN packets to localhost port 80 at a rate of 100 packets per second. This creates significant load, triggering TCP congestion control, retransmissions, and SACK usage.

Output captured: high traffic da2_all_metricshightraffic.csv

Important Note on Traffic Generation

The traffic for Low, Medium, and High conditions was generated by running hping3 commands once with appropriate packet counts and rates—NOT by opening multiple browser tabs. Each condition was a separate capture session with the command running in the background (WSL) while Wireshark captured packets in parallel. This ensures controlled, reproducible load conditions.

Inferences on the Network Parameters

GRAPH 1: BIF vs Throughput 

Normal: BIF 0-8, Throughput 0-800k BPS - Linear relationship, window scaling working correctly.

Mid: BIF 0-4.5e9, Throughput 0-60k BPS - Bufferbloat detected. Massive queue buildup (4.5 billion bytes in flight) yet throughput collapsed by 92.5%. The loopback interface queue is so deep that latency exceeds RTO, causing spurious retransmissions.

High: BIF 0-175,000, Throughput 0-20k BPS - Queue is managed (smaller BIF) but throughput is permanently damaged. TCP has entered congestion avoidance with minimum window.

DEEP INFERENCE:
The mid-traffic condition reveals a classic bufferbloat scenario - the interface queue grew to 4.5 BILLION bytes (approximately 4.5GB of queued data). This happens because TCP continues sending into an already-full pipe. When BIF exceeds 1e9, throughput collapses to under 60k BPS - a 99.993% efficiency drop relative to the queue size. This proves that large buffers harm TCP performance, contradicting the traditional belief that "more buffer = better throughput."

STRENGTH OF EVIDENCE: High - Clear numerical progression across three distinct regimes.

GRAPH 2: SACK Count vs Retransmissions 

Normal: SACK 0-4, Retransmissions 0-4 - Slightly positive correlation, but both remain low.

Mid: SACK 0-2, Retransmissions 0-60 - Weak correlation. Despite SACK being present (up to 2.0), retransmissions exploded to 60. SACK is trying to help but cannot overcome bufferbloat.

High: SACK 0-1, Retransmissions 0-12 - Moderate correlation. SACK usage is lower because the connection is in severe congestion avoidance.

DEEP INFERENCE:
SACK's effectiveness has an operational range. When retransmissions are below 10, SACK shows strong correlation (higher SACK = fewer unnecessary retransmits). But when retransmissions exceed 20 (mid-traffic), the correlation breaks - SACK is present but overwhelmed. The SACK effectiveness threshold is approximately 15 retransmissions per second. Beyond this, no amount of selective acknowledgment can save throughput because the bottleneck is queue occupancy, not loss detection.

STRENGTH OF EVIDENCE: High - Shows clear SACK saturation point.

GRAPH 3: Window Size vs Throughput 

Normal: Window size -0.04 to 0.04, Throughput 0-800k - Window size variations correlate with throughput changes (AIMD sawtooth).

Mid: Window size compressed, Throughput <60k - Window is clamped near minimum. The congestion window (cwnd) has been reduced to 1-2 MSS due to persistent loss.

High: Window size -0.04 to 0.04, Throughput <20k - Window is oscillating but at much lower amplitude. TCP is in "congestion collapse" - each window increase triggers loss, forcing multiplicative decrease before any useful throughput is achieved.

DEEP INFERENCE:
The window size values (negative values are an artifact of data representation) show that TCP Reno's AIMD algorithm enters a death spiral in high traffic. Each additive increase (+1 MSS per RTT) triggers packet loss, causing multiplicative decrease (cwnd = cwnd/2). When the bottleneck buffer is large (mid-traffic), this oscillation period lengthens but amplitude remains high. When the buffer is moderate (high-traffic), the oscillation frequency increases but amplitude collapses. The critical cwnd threshold appears to be 4-6 MSS - below this, TCP cannot achieve meaningful throughput regardless of loss recovery mechanism.

STRENGTH OF EVIDENCE: Medium - Window size data is noisy but trend is clear.

GRAPH 4: BIF vs Time Series 

Normal: BIF oscillates between 0-8 over time - Classic sawtooth pattern of TCP congestion avoidance. Each cycle: increase until loss, then drop.

Mid: BIF at 4.5e9 for extended periods - Bufferbloat plateau. The queue fills and stays full. This is pathological - packets are spending seconds (potentially tens of seconds) in the queue.

High: BIF between 0-175,000, cycling every ~200 seconds - Queue is being drained periodically. The system oscillates between "full buffer" and "empty buffer" states.

DEEP INFERENCE:
The time-series data reveals three distinct TCP regimes:

Regime	BIF Behavior	TCP State
Normal	0-8 oscillation	Healthy AIMD
Mid	4.5e9 plateau	Bufferbloat (queue never drains)
High	0-175k oscillation	Congestion avoidance with recovery

The mid-traffic plateau is particularly concerning - it indicates that the packet arrival rate consistently exceeds the departure rate. On loopback, this shouldn't happen unless the traffic generator (hping3) is overwhelming the TCP stack's ability to process ACKs. This suggests a receiver-side bottleneck - the system cannot ACK packets fast enough, causing the sender's flight size to explode.

STRENGTH OF EVIDENCE: High - Clear visual distinction between three regimes.

GRAPH 5: Retransmissions vs Goodput 

Normal: Retransmissions 0-4, Goodput 0-1.2M BPS - Inverse correlation. Each retransmission reduces goodput by approximately 200k-300k BPS.

Mid: Retransmissions 0-60, Goodput <60k BPS - Extreme inverse correlation. At retransmission count of 60, goodput approaches zero. The cost of each retransmission is catastrophic.

High: Retransmissions 0-12, Goodput <20k BPS - Moderate inverse correlation. Each retransmission costs ~1.5k BPS.

DEEP INFERENCE:
The marginal cost of a retransmission increases non-linearly with congestion:

• Normal traffic: 1 retransmission costs ~250k BPS

• Mid traffic: 1 retransmission costs ~1,000 BPS (but goodput is already low)

• High traffic: 1 retransmission costs ~1.5k BPS

This non-linearity proves that retransmissions in mild congestion are more damaging proportionally than in severe congestion - because in mild congestion, you had high goodput to lose. In severe congestion, there's nothing left to lose. The most dangerous zone is the transition from normal to mid, where retransmissions first appear.

STRENGTH OF EVIDENCE: High - Clear data across all three conditions.

GRAPH 6: SACK Count vs DupACKs 

Normal: SACK 0-4, DupACKs 0-30 - Positive correlation. More duplicate ACKs trigger more SACK blocks.

Mid: SACK 0-2, DupACKs 0-35 - Similar correlation but SACK max is lower. Duplicate ACKs are abundant but SACK is not increasing proportionally.

High: SACK 0-1, DupACKs 0-10 - Weak correlation. Both metrics are suppressed.

DEEP INFERENCE:
The dupACK-to-SACK ratio changes with congestion:

Condition	Max DupACKs	Max SACK	Ratio (DupACK:SACK)
Normal	30	4.0	7.5:1
Mid	35	2.0	17.5:1
High	10	1.0	10:1

In mid-traffic, the ratio doubles - meaning more duplicate ACKs are required to generate each SACK block. This indicates that the receiver's SACK generation is being delayed or throttled, likely due to the receiver-side bottleneck identified earlier. The system is processing ACKs slower than packets arrive, causing duplicate ACK storms before SACK can be sent.

STRENGTH OF EVIDENCE: High - Quantifiable ratio change.

GRAPH 8: BIF vs SACK Count 

Normal: BIF 0-8, SACK 0-4 - SACK appears only when BIF > 2. Threshold behavior.

Mid: BIF 0-4.5e9, SACK 0-2 - SACK is present across all BIF levels but maxes at 2.0. Even at extreme BIF, SACK cannot exceed 2 blocks.

High: BIF 0-175,000, SACK 0-1 - SACK max is 1.0, indicating only one SACK block per ACK.

DEEP INFERENCE:
The maximum SACK blocks per ACK decreases as congestion increases:

• Normal: Up to 4 SACK blocks

• Mid: Up to 2 SACK blocks

• High: Up to 1 SACK block

This is likely due to the receiver's SACK table size limitation. TCP receivers maintain a SACK table (typically 3-4 entries). In severe congestion, out-of-order packets exceed the table size, causing older SACK blocks to be discarded. The receiver can only report the most recent gaps. This limits the sender's ability to perform selective retransmission, forcing more conservative recovery (timeout or fast retransmit of entire window).

STRENGTH OF EVIDENCE: High - Clear monotonic decrease in max SACK blocks.

Conclusion

This Digital Assignment successfully analyzed TCP performance metrics—throughput, goodput, retransmission rate, SACK usage, duplicate ACKs, and out-of-order packets—under Normal, Medium, and High traffic conditions. The data clearly shows that while TCP handles moderate load gracefully, high traffic triggers aggressive congestion control, causing throughput collapse and elevated retransmission rates. SACK provides measurable benefits but cannot prevent congestion collapse when traffic exceeds network capacity. These findings reinforce the importance of proper traffic engineering and modern congestion control algorithms in real-world deployments.

Github repository

https://github.com/santhosh-vijayakumar/-Analysis-of-TCP-Performance-Metrics-Under-Varying-Network-Traffic-Conditions/tree/main

References

Wireshark Documentation: https://www.wireshark.org/docs/

hping3 Manual: https://linux.die.net/man/8/hping3

https://youtu.be/1eJHqyyjHqk?si=UnGXD7u4XKIJpiw4

https://youtu.be/nTQYA432h_k?si=X7Co7imEYl-79Dm_

https://youtu.be/_19UdEtj6Ak?si=4G9SnLiwJyauN4qG

https://youtu.be/hfxM_kriYXc?si=L4rDu-II1laUdLHr

https://youtu.be/HTQLipAG27I?si=aet-KLZEQGaFTdtF

TCP RFC 793, RFC 2018 (SACK), RFC 5681 (Congestion Control)