Transmission control protocol (TCP) is a reliable, widely used protocol on the Internet. It provides opportunities for both flow control (the receiver regulates the speed of the transmission) and congestion control (the sender must react to overload conditions in the network). Both controls are based on acknowledgements returned by the receiver. In every acknowledgement, the receiver advertises a window that reflects available buffer space. When the receiver returns an acknowledgement with a window of zero, the sender must stop sending (flow control). If an acknowledgement is not received, the sender assumes congestion and slows down (congestion control).

Incast congestion typically happens in a data center network when multiple servers, all connected to the same switch, are sending data simultaneously to a common destination, such that the switch buffer overflows, resulting in packet loss. This paper proposes a method for incast congestion control for TCP (ICTCP), which tries to avoid this packet loss. The amazing thing about ICTCP is that the receive window (normally used for flow control) is now used to avoid congestion. Therefore, it is not really congestion control, but rather congestion avoidance.

For this purpose, the receive windows of all TCP connections are dynamically adapted: a receive window is increased if measured throughput is close to expected throughput and there is still available bandwidth. If there is not enough available bandwidth, or if measured throughput deviates too much from expected throughput, the window is decreased. In this respect, ICTCP functions much like TCP Vegas.

The experimental results are very convincing: the throughput remains very stable when the number of senders is increasing, while there is only a slight increase in the number of timeouts.

Implementing ICTCP does not require any modification or extension of the TCP protocol. Senders are not affected at all. Only the receiver needs to implement ICTCP as an additional driver between the network interface driver and the protocol stack.

The approach only works in a very restricted data center topology, where connections have very small delays, and will not apply to the Internet in general. In the more general case, explicit congestion notification (ECN) is also needed, but the authors do not elaborate on this. From the text, it is also not clear how the traditional TCP congestion control at the sending end reacts to ICTCP. Is this congestion control still useful? Does it still work?