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

A QUIC Implementation for ns-3

Quick UDP Internet Connections (QUIC) is a recently proposed transport protocol, currently being standardized by the Internet Engineering Task Force (IETF). It aims at overcoming some of the shortcomings of TCP, while maintaining the logic related to flow and congestion control, retransmissions and acknowledgments. It supports multiplexing of multiple application layer streams in the same connection, a more refined selective acknowledgment scheme, and low-latency connection establishment. It also integrates cryptographic functionalities in the protocol design. Moreover, QUIC is deployed at the application layer, and encapsulates its packets in UDP datagrams. Given the widespread interest in the new QUIC features, we believe that it is important to provide to the networking community an implementation in a controllable and isolated environment, i.e., a network simulator such as ns-3, in which it is possible to test QUIC's performance and understand design choices and possible limitations. Therefore, in this paper we present a native implementation of QUIC for ns-3, describing the features we implemented, the main assumptions and differences with respect to the QUIC Internet Drafts, and a set of examples.Comment: 8 pages, 4 figures. Please cite it as A. De Biasio, F. Chiariotti, M. Polese, A. Zanella, M. Zorzi, "A QUIC Implementation for ns-3", Proceedings of the Workshop on ns-3 (WNS3 '19), Firenze, Italy, 201

Experimental performance of DCCP over live satellite and long range wireless links

We present experimental results for the performance over satellite and long range wireless (WiMax) links of the new TCP-Friendly Rate Control (TFRC) congestion control mechanism from the Datagram Congestion Control Protocol (DCCP) proposed for use with real-time traffic. We evaluate the performance of the standard DCCP/CCID3 algorithm and identify two problem areas: the measured DCCP/CCID3 rate is inferior to the rate achievable with standard TCP and a significant rate oscillation continuously occurs making the resulting rate variable even in the short term. We analyse the links and identify the potential causes, i.e. long and variable delay and link errors. As a second contribution, we propose a change in the DCCP/CCID3 algorithm in which the number of feedback messages is increased from the currently standard of at least one per return trip time. Although it is recognised that the increase in control traffic may decrease the overall efficiency, we demonstrate that the change results in higher data rates which are closer to what is achievable with TCP on those networks and that the overhead introduced remains acceptable

Transport Protocol Throughput Fairness

Interest continues to grow in alternative transport protocols to the Transmission Control Protocol (TCP). These alternatives include protocols designed to give greater efficiency in high-speed, high-delay environments (so-called high-speed TCP variants), and protocols that provide congestion control without reliability. For the former category, along with the deployed base of ‘vanilla’ TCP – TCP NewReno – the TCP variants BIC and CUBIC are widely used within Linux: for the latter category, the Datagram Congestion Control Protocol (DCCP) is currently on the IETF Standards Track. It is clear that future traffic patterns will consist of a mix of flows from these protocols (and others). So, it is important for users and network operators to be aware of the impact that these protocols may have on users. We show the measurement of fairness in throughput performance of DCCP Congestion Control ID 2 (CCID2) relative to TCP NewReno, and variants Binary Increase Congestion control (BIC), CUBIC and Compound, all in “out-of-the box” configurations. We use a testbed and endto- end measurements to assess overall throughput, and also to assess fairness – how well these protocols might respond to each other when operating over the same end-to-end network path. We find that, in our testbed, DCCP CCID2 shows good fairness with NewReno, while BIC, CUBIC and Compound show unfairness above round-trip times of 25ms

ATP: a Datacenter Approximate Transmission Protocol

Many datacenter applications such as machine learning and streaming systems do not need the complete set of data to perform their computation. Current approximate applications in datacenters run on a reliable network layer like TCP. To improve performance, they either let sender select a subset of data and transmit them to the receiver or transmit all the data and let receiver drop some of them. These approaches are network oblivious and unnecessarily transmit more data, affecting both application runtime and network bandwidth usage. On the other hand, running approximate application on a lossy network with UDP cannot guarantee the accuracy of application computation. We propose to run approximate applications on a lossy network and to allow packet loss in a controlled manner. Specifically, we designed a new network protocol called Approximate Transmission Protocol, or ATP, for datacenter approximate applications. ATP opportunistically exploits available network bandwidth as much as possible, while performing a loss-based rate control algorithm to avoid bandwidth waste and re-transmission. It also ensures bandwidth fair sharing across flows and improves accurate applications' performance by leaving more switch buffer space to accurate flows. We evaluated ATP with both simulation and real implementation using two macro-benchmarks and two real applications, Apache Kafka and Flink. Our evaluation results show that ATP reduces application runtime by 13.9% to 74.6% compared to a TCP-based solution that drops packets at sender, and it improves accuracy by up to 94.0% compared to UDP