Proportional Rate Reduction for TCP

Abstract

Packet losses increase latency for Web users. Fast recovery is a key mechanism for TCP to recover from packet losses. In this paper, we explore some of the weaknesses of the standard algorithm described in RFC 3517 and the non-standard algorithms implemented in Linux. We find that these algorithms deviate from their intended behavior in the real world due to the combined effect of short flows, application stalls, burst losses, acknowledgment (ACK) loss and reordering, and stretch ACKs. Linux suffers from excessive congestion window reductions while RFC 3517 transmits large bursts under high losses, both of which harm the rest of the flow and increase Web latency.Our primary contribution is a new design to control transmission in fast recovery called proportional rate reduction (PRR). PRR recovers from losses quickly, smoothly and accurately by pacing out retransmissions across received ACKs. In addition to PRR, we evaluate the TCP early retransmit (ER) algorithm which lowers the duplicate acknowledgment threshold for short transfers, and show that delaying early retransmissions for a short interval is effective in avoiding spurious retransmissions in the presence of a small degree of reordering. PRR and ER reduce the TCP latency of connections experiencing losses by 3-10% depending on the response size. Based on our instrumentation on Google Web and YouTube servers in U.S. and India, we also present key statistics on the nature of TCP retransmissions.

Automated Attack Discovery in TCP Congestion Control Using a Model-guided Approach

“…Given the different variants of TCP congestion control algorithms, features, and optimizations [8], [7], [17], [28], [35], [34], [13] any implementation has to make choices about what configuration and combination of features will be provided. This leads to minor differences in congestion control behavior between implementations which can enable or prevent particular attacks or even attack classes.…”

“…This FSM is based on the classic TCP New Reno [19], [4]. We then discuss op- tional improvements and variants like SACK [8], DSACK [7], TLP [17], PRR [28], FRTO [35], and others [34], [13].…”

“…These include SACK [8], DSACK [7], TLP [17], PRR [28], CUBIC [34], and RACK [13]. These variations and optimizations consist of fairly minor changes to the basic New Reno algorithm.…”

“…SACK simply uses a more accurate method to detect this condition. Similarly, PRR [28] modifies New Reno by adopting paced packet sending during the self-loop in fast recovery. TLP [17] introduces a new, faster timeout state before exponential backoff.…”

“…This is not an easy problem as there are several implemented congestion control algorithms such as Reno [4], New Reno [19], CUBIC [34], Compound TCP [39], and Vegas [9]. Implementations may also choose to include an Application Limited state, adjustable dupACKctr thresholds, and optional enhancements like SACK [8], DSACK [7], TLP [17], F-RTO [35], and PRR [28]. Additionally, we desire to do this without modifying the sender or making assumptions about what kind of debugging information it makes available.…”