Question

Suppose TCP is used over a lossy link that loses on average one segment in four. Assume the bandwidth \(x\) delay window size is considerably larger than four segments. (a) What happens when we start a connection? Do we ever get to the linearincrease phase of congestion avoidance? (b) Without using an explicit feedback mechanism from the routers, would TCP have any way to distinguish such link losses from congestion losses, at least over the short term? (c) Suppose TCP senders did reliably get explicit congestion indications from routers. Assuming links as above were common, would it be feasible to support window sizes much larger than four segments? What would TCP have to do?

Short answer

Frequent losses prevent reaching linear increase phase. TCP assumes all losses are congestion-related without feedback. With explicit congestion notifications, larger window sizes could be supported.

Step-by-step solution

Understanding the Problem Setup

TCP is used over a lossy link that loses one segment in four on average. The bandwidth-delay window size is considerably larger than four segments.

Analyze Part (a)

(a) Starting a connection under these conditions means TCP will initially go through slow start. During slow start, it increases its congestion window (cwnd) exponentially until a loss is detected. Given the high loss rate (1 in 4), it is unlikely to reach the linear increase phase of congestion avoidance because losses occur too frequently, causing repeated fallbacks.

Analyze Part (b)

(b) Without an explicit feedback mechanism, TCP cannot distinguish between losses due to congestion and other types of losses (e.g., due to link errors) in the short term. TCP assumes all losses are due to congestion and will trigger congestion control algorithms like multiplicative decrease and slow start.

Analyze Part (c)

(c) If reliable explicit congestion notifications (ECN) were provided by routers, TCP could distinguish between congestion-induced losses and random link losses. With such notifications, TCP could maintain larger window sizes by only reducing its cwnd in response to actual congestion signals, not random losses. This would help TCP to efficiently utilize the higher bandwidth-delay product.

Key concepts

TCP Congestion Control

TCP (Transmission Control Protocol) is designed to ensure reliable data transmission between sender and receiver. One of the key components of TCP is its congestion control mechanism.
Congestion control helps in managing traffic in a network to avoid congestion, which occurs when there is an overload of packets being sent. It involves several strategies such as slow start, congestion avoidance, fast retransmit, and fast recovery to handle data flow. In the case of slow start, TCP increases the congestion window size exponentially until it detects packet loss.
However, in lossy networks where packet loss happens frequently (like losing one segment in four), TCP might not move beyond the slow start phase. This is because the frequent losses will cause TCP to reset its congestion window repeatedly, preventing it from reaching the linear increase phase of congestion avoidance.

Explicit Congestion Notifications (ECN)

Explicit Congestion Notifications (ECN) is a network protocol feature that allows for congestion detection without dropping packets. It involves marking packets instead of dropping them to signal the presence of congestion.
ECN requires the cooperation of both routers and TCP endpoints. When a router experiences congestion, it marks the packet header instead of dropping the packet. Upon receiving a marked packet, the TCP receiver sends this information back to the sender. The sender, in turn, adjusts its congestion window accordingly.
This mechanism can be particularly useful in lossy networks. By distinguishing between congestion-induced losses and random link losses, TCP can avoid unnecessary reductions in its congestion window. Consequently, ECN can help in maintaining larger window sizes and better utilization of available bandwidth.

Bandwidth-Delay Product

The Bandwidth-Delay Product (BDP) is a crucial concept for understanding network performance. It is the product of a data link's capacity (bandwidth) and its round-trip time (RTT).
BDP indicates the maximum amount of data that can be in transit in the network at any given time. For instance, if a link has a bandwidth of 1 Mbps and an RTT of 100 ms, the BDP would be 100 kb.
In TCP, having a window size equal to the BDP ensures optimal utilization of the link's capacity. If the window size is too small compared to the BDP, the link will not be fully utilized. Conversely, if the window size exceeds the BDP, congestion could occur, leading to packet loss and reduced performance.
Understanding and calculating the BDP helps in configuring the TCP window size to maximize throughput, especially over high bandwidth but high-delay networks such as satellite links.