Removing Exponential Backoff from TCP

Removing Exponential Backoff from TCP

Amit Mondal

Aleksandar Kuzmanovic

EECS Department

Northwestern University

http://networks.cs.northwestern.edu

2 A. Mondal Removing Exponential Backoff from TCP

Se

nd

ing

Ra

te

T ime

packet loss• Slow-start phase • Double the sending ... ... rate each round-trip ... time • Reach high throughput ...quickly

TCP Congestion Control


TCP Congestion ControlS

en

din

g R

ate

T ime

packet loss

• Additive Increase – ...Multiplicative Decrease • Fairness among flows


TCP Congestion ControlS

en

din

g R

ate

T ime

packet loss

• Exponential•.backoff• System stability


Our breakthroughS

en

din

g R

ate

T ime

packet loss

• Exponential backoff• fundamentally wrong!


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


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 environmentFinite flow sizes and skewed traffic distributionIncreased 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

Trace-ITrace-IITrace-III

End-to-end performance does not degrade after removing exponential backoff from TCP


Impact of (minRTO, initRTO) parameters

RFC 2988 recommendation– (1.0s, 3.0s)

Current practice– (0.2s, 3.0s)

Aggressive version– (0.2s, 0.2s)


Impact of minRTO and initRTO

TCP

TCP*(3)

TCP*(∞)

Aggressive minRTO and initRTO parameters do not hurt e2e performance as long as endpoints uphold implicit packet conservation principle

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


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


Impact on network efficiency

< 5% flows experience multiple bottleneck α = 0.002475 for (1%, 5%) very small

Fraction of dead packet at upstream bottleneck:


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

Trace-I

Trace-II

Trace-III

Improves response times distributions of

both set of flows

Multiple-bottlenecked flows improve response times, while upstream single-bottlenecked flows only

marginally degrades response times

Similar result as Trace-II

Multiple-bottlenecked flows improve their response times without causing catastrophic effect other flows even when their presence is significant


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

Response times distribution improves in absence of p2p traffic

The improvement is more significant in presence 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



TCPTCP*(3)TCP*(∞)


Removing Exponential Backoff from TCP

Documents

Transcript of Removing Exponential Backoff from TCP