TCP Dynamics - Dave Adelin Sima - 2480251

This report examines Window Scaling and Selective Acknowledgement and their impact on TCP
behavior under packet loss. These features are critical in modern networking to maintain stable
connections and efficient data transfer in the face of high-latency or lossy connections. Wireshark was
used to capture packet data during file transfers under controlled packet loss. I/O and TCP Stream
graphs were generated from the data to visualize throughput, retransmissions and acknowledgements.
Additionally, this report explores the impact of various combinations of WS and SA being enabled or
disabled, analyzing how these configurations influence TCP performance under different packet loss
scenarios. The goal is to quantify performance degradation and understand TCP strategies with and
without these features.

Window Scaling

The original TCP specification (RFC 793, 1981) included a 16-bit receive window size, limiting the
maximum amount of unacknowledged data to 65,535 bytes. This restriction severely hampers
performance in high-bandwidth and high-latency networks, where the amount of data that could be in
transit at once is insufficient to fully utilize available resources.

Window Scaling was introduced in RFC 1323 (1992) to overcome this limitation. It extends the effective
window size by applying a scaling factor, which is negotiated during the SYN handshake. This scaling
factor multiplies the advertised window size by a power of 2, allowing it to support values up to 1 GB
(2^30 bytes).

The scaling factor is encoded in the TCP Options field of the SYN packet, ensuring backward
compatibility with existing TCP implementations. By extending the window size, TCP can handle larger
volumes of in-flight data, reducing the frequency at which the sender needs to pause for
acknowledgments. This can be seen in Figure 1 below.

Figure 1: Effect of window size on throughput

1
Selective Acknowledgement

The original TCP specification (RFC 793, 1981) used cumulative acknowledgments, which required the
receiver to acknowledge only the last contiguous byte of data successfully received. This approach
works well under normal conditions but struggles with packet loss, as any missing packet causes all
subsequent packets to appear as unacknowledged, necessitating retransmissions.

Selective Acknowledgement was introduced in RFC 2018 (1996) to address this inefficiency. SA allows
the receiver to acknowledge specific blocks of successfully received data, even if earlier segments are
missing. This prevents unnecessary retransmission of correctly received packets, significantly improving
efficiency in lossy networks.

The SACK option is encoded in the TCP Options field of the header and operates by listing ranges of
successfully received data. This information enables the sender to retransmit only the missing segments,
optimizing data recovery and reducing bandwidth waste.

Figure 2: Effect of selective acknowledgement on throughput

2
Analysis of classic TCP (No SA, No WS)
The ports in the 4030-4039 range are configured without SA or WS. This setup relies solely on
cumulative acknowledgments and a fixed 65,535-byte receive window, providing a consistent baseline to
analyse original TCP (RFC 793) behaviour under varying levels of packet loss. Each port was tested
using progressively higher packet loss rates, highlighting the inefficiencies inherent to this configuration.
The initial file size chosen for the transfer was 256KB loss rates were 0%, 15%, 35% and 45%. Note that
the scaling of the axis

Port 4030 - 256KB: Baseline (No Packet Loss)

Port 4030 served as a baseline with no intentional packet loss. Since there was no intended packet loss,
it proved to be just fine for this application. The transfer took 0.24s with a throughput of 1066.67 KB/s.

Figure 3: Wireshark I/O Graph for a 256KB file transfer, 0% packet loss, no SA, no WS

3
Port 4033 - 256KB: 15% Packet Loss

In the presence of 15% packet loss, port 4033 demonstrated noticeable [Link] a 256 KB test
file, the I/O graph showed retransmission spikes and frequent delays caused by cumulative
acknowledgments. We can see the lack of SA and WS has a clear effect on packet transmission. The
high ratio of TCP errors to successful packets reflected the inefficiency of this configuration under even
moderate packet loss. The transfer took 4.84s with a throughput of 52.89 KB/s.

Figure 4: Wireshark I/O Graph for a 256KB file transfer, 15% packet loss, no SA, no WS

4
Port 4037 - 64KB: 35% Packet Loss

Port 4037, tested using a 64 KB file due to failure with the 256KB file, experienced severe performance
degradation. The I/O graph showed abrupt stops and starts as the sender struggled to recover from
losses. It is clear how a lack of SA and WS make this transfer extremely sluggish as when packets have
a hard time getting through, and when they do get through they may not be ack’d anyway as other
packets-in-flight have been lost. The combination of high retransmission overhead and limited throughput
created a high ratio of TCP errors to successful packets. The transfer took 77.24s with a throughput of
0.8286 KB/s.

Figure 5: Wireshark I/O Graph for a 64KB file transfer, 35% packet loss, no SA, no WS

5
Port 4039 - 16KB: 45% Packet Loss

Port 4039, tested with a 16 KB file due to completion issues with the 64KB file, demonstrated the worst
performance under extreme packet loss. The I/O graph reflected substantial delays between successful
transmissions. This configuration resulted in a very high error-to-successful-packet ratio, rendering it
highly inefficient under such adverse conditions. The transfer took 9.63s with a throughput of 1.6615
KB/s. A deceptive statistic.

Figure 6: Wireshark I/O Graph for a 16KB file transfer, 45% packet loss, no SA, no WS

Overall the results fit the expected trend, except for Port 4039. While the throughput for Port 4039 might
seem better compared to Port 4037 it’s important to note that both of these file transfers took 10s of
attempts in order to get just one complete transfer. Therefore the throughput calculated from these file
transfers are most probably not representative of the real throughput.

Port and File Size Transfer Time (s) Throughput (KB/s)

Port 4030 - 256KB 0.24 1066.67

Port 4033 - 256KB 4.84 52.89

Port 4037 - 64KB 77.24 0.8286

Port 4039 - 16KB 9.63 1.6615

6
Comparing combinations of SA and WS at 20% Packet Loss
To evaluate how SA and WS influence TCP performance under adverse conditions, combinations of
these features were tested at 20% packet loss. Packet loss is a common challenge in real-world
networks, and understanding the individual and combined impacts of SA and WS provides valuable
insights into their effectiveness. SA reduces retransmissions by acknowledging non-contiguous data
blocks, while WS increases the amount of in-flight data, improving throughput in high-latency conditions.
Testing these features individually and together allows for a detailed analysis of their interactions and
trade-offs, showcasing how they contribute to mitigating packet loss and enhancing TCP efficiency.

Port 4004: 20% Packet Loss, SA, WS

Port 4004, which has both SA and WS enabled, demonstrated the highest performance during the test
under 20% packet loss. SA's ability to pinpoint and retransmit only the missing segments drastically
reduced retransmission overhead. Combined with WS, which allowed a larger receive window, the
sender was able to transmit higher volumes of in-flight data before needing acknowledgments. This
configuration achieved an optimal balance between throughput and recovery, as evident by the low ratio
of TCP errors to successful packets. Most errors resulted in rapid recovery, preventing performance
bottlenecks. The combination of these features is particularly effective in environments with significant
packet loss. The transfer took 13.17s with a throughput of 77.75 KB/s.

Figure 7: Wireshark I/O Graph for a 1024KB file transfer, 20% packet loss, SA, WS

7
Port 4014: 20% Packet Loss, No SA, WS

Port 4014, with WS enabled but SA disabled, showed moderate performance. While WS increased the
amount of data in flight by allowing larger receive windows, the absence of SA led to inefficiencies in
retransmissions. When a packet was lost, the sender was forced to retransmit all subsequent packets,
even if some were already received successfully, the inability to selectively retransmit missing packets
was a significant drawback in handling packet loss. This resulted in an inflated ratio of TCP errors to
successful packets. The throughput was higher than the configuration without WS, but redundant
retransmissions consumed bandwidth unnecessarily, limiting overall efficiency. The transfer took 20.73s
with a throughput of 12.35 KB/s.

Figure 8: Wireshark I/O Graph for a 256KB file transfer, 20% packet loss, No SA, WS

8
Port 4024: 20% Packet Loss, SA, No WS

Port 4024, which enabled SA but lacked WS, performed reasonably well under 20% packet loss. SA
minimized retransmission overhead by acknowledging non-contiguous data blocks, ensuring only the
missing segments were retransmitted. However, the small receive window limited the amount of in-flight
data to 65,535 bytes, significantly restricting throughput. While the ratio of TCP errors to successful
packets was only slightly lower compared to Port 4014, it was still lower nonetheless. This configuration
performed better than setups without SA but struggled to utilize available bandwidth fully. The transfer
took 3.87s with a throughput of 66.15 KB/s.

Figure 9: Wireshark I/O Graph for a 256KB file transfer, 20% packet loss, SA, No WS

9
Port 4034: 20% Packet Loss, No SA, No WS

Port 4034, with neither SA nor WS enabled, exhibited the poorest performance. The lack of SA meant
that any packet loss forced the sender to retransmit all subsequent packets, regardless of whether they
had already been received successfully. Additionally, lack of WS restricted the volume of in-flight data,
severely limiting throughput. Frequent redundant transmissions means more packets are sent for every
packet that hasn’t been ack’d, this skews our ratio of TCP errors to successful packets, leading to a
misleading ratio that is lower than expected. This configuration struggled to handle the 20% packet loss,
making it the least efficient and most bandwidth-wasteful setup among the tested ports. The transfer took
18.02s with a throughput of 14.21 KB/s.

Figure 10: Wireshark I/O Graph for a 256KB file transfer, 20% packet loss, No SA, No WS

10
 Port, File Size and Config Transfer Time (s) Throughput (KB/s)

Port 4004 - 1024KB - SA, WS 13.17 77.75

Port 4014 - 256KB - WS 20.73 12.35

Port 4024 - 256KB - SA 3.87 66.15

Port 4034 - 256KB - 18.02 14.21

The results in Table 2 highlight the varying impacts of SA and (WS) on TCP performance. Port 4004,
which utilized both SA and WS, delivered the best results, achieving a throughput of 77.75 KB/s in 13.17
seconds. This demonstrates the combined power of SA and WS in handling lossy connections.
Especially when compared to Port 4034 without SA nor WS. Surprisingly, Port 4024, with only SA
enabled, showed that SA alone can significantly improve performance, achieving 66.15 KB/s in 3.87
seconds, outperforming Port 4014, which relied solely on WS (12.35 KB/s in 20.73 seconds). This
disparity underscores SA's critical role in addressing packet loss by reducing retransmission overhead.

Interestingly, WS had a limited impact in isolation, likely due to the test file sizes being only about four
times the maximum window size, which constrained its potential benefits. Meanwhile, the baseline
configuration (Port 4034) without SA or WS performed the worst, with a throughput of just 14.21 KB/s
over 18.02 seconds, reaffirming the inefficiency of classic TCP in high-loss environments.

In conclusion, SA provides the most substantial improvements in lossy conditions, making it an essential
feature for modern TCP implementations. WS, while beneficial in certain scenarios, gains greater
significance when combined with SA, and larger transfer sizes. Together, these enhancements are
crucial for optimizing TCP performance, ensuring robust and efficient communication even in challenging
network conditions.

11