7,237 research outputs found

    Transport Protocol Throughput Fairness

    Get PDF
    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

    Mystique: a fine-grained and transparent congestion control enforcement scheme

    Get PDF
    TCP congestion control is a vital component for the latency of Web services. In practice, a single congestion control mechanism is often used to handle all TCP connections on a Web server, e.g., Cubic for Linux by default. Considering complex and ever-changing networking environment, the default congestion control may not always be the most suitable one. Adjusting congestion control to meet different networking scenarios usually requires modification of TCP stacks on a server. This is difficult, if not impossible, due to various operating system and application configurations on production servers. In this paper, we propose Mystique, a light-weight, flexible, and dynamic congestion control switching scheme that allows network or server administrators to deploy any congestion control schemes transparently without modifying existing TCP stacks on servers. We have implemented Mystique in Open vSwitch (OVS) and conducted extensive testbed experiments in both public and private cloud environments. Experiment results have demonstrated that Mystique is able to effectively adapt to varying network conditions, and can always employ the most suitable congestion control for each TCP connection. More specifically, Mystique can significantly reduce latency by 18.13% on average when compared with individual congestion controls

    A fine-grained and transparent congestion control enforcement scheme

    Get PDF
    In practice, a single TCP congestion control is often used to handle all TCP connections on a Web server, e.g., Cubic for Linux by default. Considering complex and ever-changing networking environment, the default congestion control algorithm may not always be the most suitable one. Adjusting congestion control usually to meet different networking scenarios requires modification of servers' TCP stacks. This is difficult, if not impossible, due to various operating systems and different configurations on the servers. In this paper, we propose Mystique, a light-weight and flexible scheme that allows administrators (or operators) to deploy any congestion control schemes transparently without changing existing TCP stacks on servers. We have implemented Mystique in Open vSwitch (OVS) and conducted extensive test-bed experiments in public cloud environments. We have extensively evaluated Mystique and the results have demonstrated that it is able to effectively adapt to varying network conditions, and can always employ the most suitable congestion control for each TCP connection. Mystique can significantly reduce latency by up to 37.8% in comparison with other congestion controls

    Beyond socket options: making the Linux TCP stack truly extensible

    Full text link
    The Transmission Control Protocol (TCP) is one of the most important protocols in today's Internet. Its specification and implementations have been refined for almost forty years. The Linux TCP stack is one of the most widely used TCP stacks given its utilisation on servers and Android smartphones and tablets. However, TCP and its implementations evolve very slowly. In this paper, we demonstrate how to leverage the eBPF virtual machine that is part of the recent versions of the Linux kernel to make the TCP stack easier to extend. We demonstrate a variety of use cases where the eBPF code is injected inside a running kernel to update or tune the TCP implementation. We first implement the TCP User Timeout Option. Then we propose a new option that enables a client to request a server to use a specific congestion control scheme. Our third extension is a TCP option that sets the initial congestion window. We then demonstrate how eBPF code can be used to tune the acknowledgment strategy.Comment: 9 pages, 8 figure

    Beyond socket options: making the Linux TCP stack truly extensible

    Get PDF
    The Transmission Control Protocol (TCP) is one of the most important protocols in today's Internet. Its specification and implementations have been refined for almost forty years. The Linux TCP stack is one of the most widely used TCP stacks given its utilisation on servers and Android smartphones and tablets. However, TCP and its implementations evolve very slowly. In this paper, we demonstrate how to leverage the eBPF virtual machine that is part of the recent versions of the Linux kernel to make the TCP stack easier to extend. We demonstrate a variety of use cases where the eBPF code is injected inside a running kernel to update or tune the TCP implementation. We first implement the TCP User Timeout Option. Then we propose a new option that enables a client to request a server to use a specific congestion control scheme. Our third extension is a TCP option that sets the initial congestion window. We then demonstrate how eBPF code can be used to tune the acknowledgment strategy.Comment: 9 pages, 8 figure

    Validation of simulated real world TCP stacks

    Get PDF
    The TCP models in ns-2 have been validated and are widely used in network research. They are however not aimed at producing results consistent with a TCP implementation, they are rather designed to be a general model for TCP congestion control. The Network Simulation Cradle makes real world TCP implementations available to ns-2: Linux, FreeBSD and OpenBSD can all be simulated as easily as using the original simplified models. These simulated TCP implementations can be validated by directly comparing packet traces from simulations to traces measured from a real network. We describe the Network Simulation Cradle, present packet trace comparison results showing the high degree of accuracy possible when simulating with real TCP implementations and briefly show how this is reflected in a simulation study of TCP throughput

    Improvements in DCCP congestion control for satellite links

    Get PDF
    We propose modifications in the TCP-Friendly Rate Control (TFRC) congestion control mechanism from the Datagram Congestion Control Protocol (DCCP) intended for use with real-time traffic, which are aimed at improving its performance for long delay (primarily satellite) links. Firstly, we propose an algorithm to optimise the number of feedback messages per round trip time (RTT) rather than use the currently standard of at least one per RTT, based on the observed link delay. We analyse the improvements achievable with proposed modification in different phases of congestion control and present results from simulations with modified ns-2 DCCP and live experiments using the modified DCCP Linux kernel implementation. We demonstrate that the changes results in improved slow start performance and a reduced data loss compared to standard DCCP, while the introduced overhead remains acceptable

    THE ANALYSIS OF VARIOUS TCP SUB-VERSIONS AND MECHANISM FOR CONGESTION AVOIDENCE

    Get PDF
    TCP, the most widely used protocol on Internet, has a major problem in that its congestion control does not allow flows to obtain full bandwidth on fast-long distance links. A Performance analysis of TCP-controlled long file transfers in a WLAN in infrastructure mode also with Comparison and Analysis of Congestion Window for HS-TCP, Full-TCP and TCP-Linux in Long Term Evolution System Model is available in the literature with one of the main assumptions being equal window size for all TCP connections. In this paper, we extend the analysis to TCP-controlled long file uploads and downloads with different TCP windows. Our approach is based on the semiMarkov process considered in [1] and [2], but with arbitrary window sizes. We present simulation results to show the accuracy of the analytical model. KEYWORDS:-WLAN, ACCESS POINTS
    corecore