Removing Exponential Backoff from TCP Amit Mondal Aleksandar Kuzmanovic EECS Department Northwestern University http://networks.cs.northwestern.edu

TCP Congestion Control Slow-start phase Double the sending ... ... rate each round-trip ... time Reach high throughput ...quickly

TCP Congestion Control Additive Increase – ...Multiplicative Decrease Fairness among flows

TCP Congestion Control Exponential .backoff System stability

Our breakthrough Exponential backoff fundamentally wrong! Rest of my presentation, I will argue (and hopefully convince) why so!

Contribution Untangle retransmit timer backoff mechanism Challenge the need of exponential backoff in TCP Demonstrate exponential backoff can be removed from TCP without causing congestion collapse Incrementally deployable two-step task

Implications Dramatically improve performance of short-lived and interactive applications Increase TCP's resiliency against low-rate (shrew attack) and high-rate (bandwidth flooding) DoS attack Other impacts by avoiding unnecessary backoffs

Background Origin on RTO backoff Adopted from classical Ethernet protocol IP gateway similar to 'ether' in shared-medium Ethernet network Exponential backoff is essential for Internet stability "an unstable system (a network subject to random load shocks and prone to congestion collapse) can be stabilized by adding some exponential damping (exponential timer backoff) to its primary excitation (senders, traffic sources)“ [Jacobson88]

Rationale behind revisions No admission control in the Internet No bound on number of active flows Stability results in Ethernet protocol not applicable IP gateway vs classical Ethernet Classical Ethernet: Throughput reduces to zero in overloaded scenarios IP gateway: Forwards packets at full capacity even in extreme congested scenarios Dynamic network environment Finite flow sizes and skewed traffic distribution Increased bottleneck capacities

Implicit Packet Conservation Principle RTO > RTT Karn-Partridge algorithm and Jacobson's algorithm ensures this End-to-end performance cannot suffer if endpoints uphold the principle Formal proof for single bottleneck case in paper Extensive evaluation with network testbed Single bottleneck Multiple bottleneck Complex topologies

Experimental methodology Testbed Emulab 64-bit Intel Xeon machine + FreeBSD 6.1 RTT in 10ms - 200ms Bottleneck 10Mbps TCP Sack + RED Workload Trace-II: Synthetic HTTP traffic based on empirical distribution Trace-I : Skewed towards shorter file-size Trace-III: Skewed towards longer file-size NS2 simulations

Evaluation TCP*(n) : sub exponential backoff algorithms No backoff for first “n” consecutive timeouts Impact of RTO backoff mechanism on response time Impact of minRTO and initRTO on end-to-end performance

Sub-exponential backoff algorithms End-to-end performance does not degrade after removing exponential backoff from TCP Trace-I Trace-II Trace-III

Impact of (minRTO, initRTO) parameters RFC 2988 recommendation (1.0s, 3.0s) Current practice (0.2s, 3.0s) Aggressive version (0.2s, 0.2s) Our key hypothesis is that setting these parameters more aggressively will not hurt the end-to-end performance as long as the endpoints uphold implicit packet conservation principle.

Impact of minRTO and initRTO Poor performance of (1.0s,3.0s) RTO pair, the CCDF tail is heaviest Improved performance both for (0.2s, 3.0s) and (0.2s, 02s) pair Aggressive minRTO and initRTO parameters do not hurt e2e performance as long as endpoints uphold implicit packet conservation principle TCP TCP*(∞) The figures depict the CCDF of response time profiles for TCP, TCP*(3) and TCP*(6) for different combination of (minRTO, initRTO) parameter. First observation is the poor performance of (1.0s, 3.0s) RTO pair; the CCDF tail is heaviest. Second observation: all figures show an improved performance for (0.2s, 3.0s) and (0.2s, 0.2s) pairs over (1s, 3s) pair although the order is not uniform. For TCP case, choosing more aggressive minRTO and initRTO and leaving the backoff untouched make the aggressive choice worse. This is because packet loss prob increases due to aggressive minRTO, initRTO parameter, and it is possible for active connections to be moved into long shutoffs, and thereby reducing their performance relative to (0.2s, 3.0s) scenario. TCP*(3)

Role of bottleneck capacity TCP*(∞) out performs classical TCP independent of bottleneck capacity

Dynamic environments ON-OFF flow arrival period Inter-burst: 50ms – 10s

Dynamic environments ON-OFF flow arrival period Inter-burst: 1 sec Time series of active connections

TCP variants and Queuing disciplines TCP Tahoe, TCP Reno, TCP Sack Droptail, RED The backoff-less TCP stacks outperform regular stacks irrespective of TCP versions and queuing disciplines

Multiple bottlenecks Dead packets Topology Packets that exhaust network resources upstream, but are then dropped downstream In multiple bottleneck scenario there is a chance that dead packets impact the performance of flows sharing the upstream bottleneck. We do modeling and extensive experiment to explore such scenarios R1 R2 R3 R4 S0 C0 S1 C1 S2 C2 L0 L1 L2 p1 p2 Till now, we have shown that independent of the location of bottleneck link (upstream or downstream), the backoff less TCP stack can only improve end-to-end performance, irrespective of TCP version and queuing disciplines. Now the concern is that when the bottleneck is downstream, near the receiver side, a more aggressive endpoint can generate large number of dead packets which get dropped at downstream. In multiple bottleneck scenario there is a chance that dead packets impact the performance of flows sharing the upstream bottleneck.

Impact on network efficiency Fraction of dead packet at upstream bottleneck: < 5% flows experience multiple bottleneck α = 0.002475 for (1%, 5%) very small

Impact on end-to-end performance What happens if the percent of multiple-bottleneck flows increases dramatically? What is the impact of backoff-less TCP approach on end-to-end performance in such scenarios? Emulab experiment Set L0/(L0+L1)= 0.25 >> current situation

Impact on end-to-end performance Improves response times distributions of both set of flows Similar result as Trace-II Multiple-bottlenecked flows improve their response times without causing catastrophic effect other flows even when their presence is significant Trace-II Multiple-bottlenecked flows improve response times, while upstream single-bottlenecked flows only marginally degrades response times Trace-I These figures show response time distribution of both two-bottleneck flows and flows sharing only the upstream bottleneck for all three kind of Traces. The left side figure shows removing backoff altogether improves the response times of both set of flows. This is because in an environment dominated by long pauses due to exponential backoff only degrades the overall response times. With trace-II, the set of multiple-bottlenecked flows improve their aggregate response times, while flows with only single upstream-bottleneck only marginally degrades their response time. The result is similar with Trace-III. Trace-III

Realistic network topologies Orbis-scaled HOT topology 10 Gbps core link 100 Mbps server edge link 1 – 10Mbps client side link 10ms link delay Workload HTTP HTTP + P2P The improvement is more significant in presence of p2p traffic Response times distribution improves in absence of p2p traffic

Incremental deployment TCP's performance degrades non-negligibly when present with TCP*(∞) Two-step Task TCP to TCP*(3) TCP*(3) to TCP*(∞)

Summary Challenged the need of RTO backoff in TCP End-to-end performance can only improve if endpoints uphold implicit packet conservation principle Extensive testbed evaluation for single bottleneck and multiple bottleneck scenario, and with complex topologies Incrementally deployable two-step task

Thank you

Impact of minRTO and initRTO Aggressive minRTO and initRTO parameters do not hurt e2e performance as long as endpoints uphold implicit packet conservation principle TCP TCP*(3) TCP*(∞)

Impact of minRTO and initRTO Aggressive minRTO and initRTO parameters do not hurt e2e performance as long as endpoints uphold implicit packet conservation principle TCP TCP*(3) TCP*(∞)