Performance analysis of the Quick-Start TCP extension

Abstract

Abstract-Quick-Start is an experimental extension of the Transmission Control Protocol (TCP) that allows to speed up best effort data transfers. With Quick-Start, TCP hosts can request permission from the routers along a network path to send at a higher rate than allowed by the default TCP congestion control. The explicit router feedback avoids the time-consuming capacity probing by the TCP Slow-Start and is therefore particularly beneficial for underutilized paths with a high bandwidth-delay product. In this paper, the performance of the Quick-Start TCP extension is analyzed and the impact of router admission control strategies is studied. The main contribution is an analytical model that quantifies the improvement compared to default TCP Slow-Start. The model is validated by simulation results and by initial measurements with a Quick-Start implementation in the Linux operating system. Our results confirm that Quick-Start can significantly reduce the completion times of mid-sized data transfers. I. INTRODUCTIONThe Transmission Control Protocol (TCP) is the default transport protocol for best effort Internet services. Since TCP is a pure end-to-end protocol, the connection endpoints have to estimate the path characteristics in order to adapt their sending rate. However, after connection setup, or e. g. after long idle periods, it is difficult to determine an appropriate rate due to lack of information. Traditionally, the TCP congestion control uses the "Slow-Start" heuristic to probe the available bandwidth in these cases, but this is a time-consuming process, since it can require many round-trip times to reach an appropriate sending rate.The Quick-Start extension [1] addresses this issue by using explicit router feedback. It allows hosts to ask for an initial sending rate, e. g., during the TCP three-way handshake, and the routers along the path can approve, modify, or discard this request. If the Quick-Start request is approved, using a higher-than-default initial sending rate can significantly speed up high-speed best effort data transfers over paths with a large bandwidth-delay product, such as over long-distance broadband wide area networks, satellite or cellular links.Even though Quick-Start is only a minor extension of the TCP congestion control, its deployment has various implications on the architecture and performance of IP networks. An initial evaluation of Quick-Start in [2] quantifies the performance benefits compared to standard TCP and discusses basic router strategies. Yet, many details and trade-offs are not discussed in detail there, and the results are based on simulations only. This paper derives analytical approximations for

Performance Evaluation of Fast Startup Congestion Control Schemes

“…In addition to testbed measurements, we also run simulations using the Network Simulation Cradle [7] for the user-space execution of real network stack code. To the best of our knowledge, this is the first comparative study of the new fast startup schemes and thereby complements our work on Quick-Start TCP [8,9].…”

“…If all routers along the path approve the request, data transfers can start with this high rate. Further details about the Quick-Start mechanism and its implications can be found in [4,8,9].…”

“…In order to verify our simulation and measurement results we use an analytical Slow-Start model developed by Bodamer (see [8]). As shown in Fig.…”

“…Two further important parameters are the initial congestion window w and the number of segments b that a receiver acknowledges in one segment. As detailed in [8], the transfer time Γ SS (s) of a certain amount of data s in Slow-Start is…”

“…Second, Quick-Start does not improve the convergence, if the routers use an admission control strategy that prevents over-commitment (cf. [8]). Due to lack of free capacity, the Quick-Start request is denied at the bottleneck, and the second connection therefore falls back to Slow-Start.…”