Throughput and fairness of multiple TCP connections in wireless networks

TCP suffers from poor throughput performance in wireless networks. Furthermore, when multiple TCP connections compete at the base station, link errors and congestion lead to serious unfairness among the connections. Although the issue of TCP performance in wireless networks has attracted significant attention, most reports focus only on TCP throughput and assume that there is only a single connection in a congestion-free network. This paper studies the throughput and fairness of popular improvement mechanisms (the Snoop [8] and ELN [5]) and TCP variants with multiple TCP connections. Simulation results show that the improvement mechanisms under investigation are effective to improve TCP throughput in a wireless network. However, they cannot provide fairness among multiple TCP connections. From the studies presented, it is concluded that mechanisms to enhance TCP fairness are needed in wireless network

Improving the fairness of FAST TCP to new flows

It has been observed that FAST TCP, and the related protocol TCP Vegas, suffer unfairness when many flows arrive at a single bottleneck link, without intervening departures. We show that the effect is even more marked if a new flow arrives when existing flows share bandwidth fairly, and propose a simple method to ameliorate this effect

Network coding meets TCP

We propose a mechanism that incorporates network coding into TCP with only minor changes to the protocol stack, thereby allowing incremental deployment. In our scheme, the source transmits random linear combinations of packets currently in the congestion window. At the heart of our scheme is a new interpretation of ACKs - the sink acknowledges every degree of freedom (i.e., a linear combination that reveals one unit of new information) even if it does not reveal an original packet immediately. Such ACKs enable a TCP-like sliding-window approach to network coding. Our scheme has the nice property that packet losses are essentially masked from the congestion control algorithm. Our algorithm therefore reacts to packet drops in a smooth manner, resulting in a novel and effective approach for congestion control over networks involving lossy links such as wireless links. Our experiments show that our algorithm achieves higher throughput compared to TCP in the presence of lossy wireless links. We also establish the soundness and fairness properties of our algorithm.Comment: 9 pages, 9 figures, submitted to IEEE INFOCOM 200

FAST TCP: Motivation, Architecture, Algorithms, Performance

We describe FAST TCP, a new TCP congestion control algorithm for high-speed long-latency networks, from design to implementation. We highlight the approach taken by FAST TCP to address the four difficulties which the current TCP implementation has at large windows. We describe the architecture and summarize some of the algorithms implemented in our prototype. We characterize its equilibrium and stability properties. We evaluate it experimentally in terms of throughput, fairness, stability, and responsiveness

ABC: A Simple Explicit Congestion Controller for Wireless Networks

We propose Accel-Brake Control (ABC), a simple and deployable explicit congestion control protocol for network paths with time-varying wireless links. ABC routers mark each packet with an "accelerate" or "brake", which causes senders to slightly increase or decrease their congestion windows. Routers use this feedback to quickly guide senders towards a desired target rate. ABC requires no changes to header formats or user devices, but achieves better performance than XCP. ABC is also incrementally deployable; it operates correctly when the bottleneck is a non-ABC router, and can coexist with non-ABC traffic sharing the same bottleneck link. We evaluate ABC using a Wi-Fi implementation and trace-driven emulation of cellular links. ABC achieves 30-40% higher throughput than Cubic+Codel for similar delays, and 2.2X lower delays than BBR on a Wi-Fi path. On cellular network paths, ABC achieves 50% higher throughput than Cubic+Codel