TCP Nice: A Mechanism for Background Transfers

Transcription

1 Improving Internet Availability and Reliability TCP : A Mechanism for Background Transfers Z. Morley Mao Lecture 7 Feb 2, 2004 Arun Venkataramani, Ravi Kokku, Mike Dahlin Laboratory of Advanced Systems Research(LASR) Computer Sciences, University of Texas at Austin Z. Morley Mao, Winter Z. Morley Mao, Winter What are background transfers? Desired Properties Data that humans are not waiting for Non-deadline-critical Unlimited demand Examples - Prefetchedtraffic on the Web - File system backup - Large-scale data distribution services - Background software updates - Media file sharing Utilization of spare network capacity No interference with regular transfers - Self-interference applications hurt their own performance - Cross-interference applications hurt other applications performance Z. Morley Mao, Winter Z. Morley Mao, Winter Goal: Self-tuning protocol TCP Many systems use magic numbers - Prefetch threshold [DuChamp99, Mogul96, ] - Rate limiting [Tivoli01, Crovella98, ] - Off-peak hours [Dykes01, many backup systems, ] Goal: abstraction of free infinite bandwidth Applications say what they want - OS manages resources and scheduling Limitations of manual tuning - Difficult to balance concerns - Proper balance varies over time Burdens application developers - Complicates application design - Increases risk of deployment - Reduces benefits of deployment Self tuning transport layer - Reduces risk of interference with FG traffic - Significant utilization of spare capacity by BG - Simplifies application design Z. Morley Mao, Winter Z. Morley Mao, Winter

2 Why change TCP? Traditional TCP TCP does network resource management - Need flow prioritization Alternative: router prioritization + More responsive, simple one bit priority - Hard to deploy Question: - Can end-to-end congestion control achieve noninterference and utilization? Adjusts congestion window (cwnd) - Competes for fair share of BW (=cwnd/rtt) Packet losses signal congestion - Additive Increase no losses Increasecwnd by one packet per RTT - Multiplicative Decrease: one packet loss (triple duplicate ack) halve cwnd multi-packet loss set cwnd = 1 Problem: signal comes after damage done Z. Morley Mao, Winter Z. Morley Mao, Winter TCP TCP Vegas Proactively detects congestion Early congestion detection using RTTs Uses increasing RTT as congestion signal - Congestion incr. queue lengths incr. RTT Aggressive responsiveness to congestion Additive decrease on early congestion Restrict number of packets maintained by each flow at bottleneck router Only modifies sender-side congestion control - Receiver and network unchanged - TCP friendly Small queues, yet good utilization Z. Morley Mao, Winter Z. Morley Mao, Winter m Throughput 1/minRTT W * a E = W / minrtt A = W /observedrtt Diff = (E A)/minRTT TCP Vegas b Diff Expected Actual Window if(diff < α / minrtt) W Ã W + 1 else if(diff > β / minrtt) W Ã W - 1 Additive decrease when packets queue Z. Morley Mao, Winter TCP Basic algorithm - 1. Early Detection thresh. queue length incr. in RTT - 2. Multiplicative decrease on early congestion - 3. Maintain small queues like Vegas - 4. Allow cwnd < 1.0 per-ackoperation: - if(currtt > minrtt + threshold*(maxrtt minrtt)) numcong++; per-round operation: - if(numcong > f.w) W W/2 else { Vegas congestion control } Z. Morley Mao, Winter

3 : the works Evaluation of Add * Add * Add * Add * Add + Mul + t.b Mul + Mul + Analysis Simulation micro-benchmarks m minrtt = t B pkts maxrtt = t+b/m WAN measurements Case studies Non-interference getting out of the way in time Utilization maintaining a small queue Z. Morley Mao, Winter Z. Morley Mao, Winter Theoretical Analysis TCP Evaluation Prove small bound on interference Main result interference decreases exponentially with bottleneck queue capacity, independent of the number of flows Guided algorithmic design - All 4 aspects of protocol essential Unrealistic model - Fluid approximation - Synchronous packet drop Micro-benchmarks (ns simulation) - test interference under more realistic assumptions Near optimal interference 10-X less than standard TCP - determine if can get useful throughput 50-80% of spare capacity - test under stressful network conditions - test under restricted workloads, topologies Z. Morley Mao, Winter Z. Morley Mao, Winter TCP Evaluation NS Simulations Measure prototype on WAN + test interference in real world + determine if throughput is available to - limited ability to control system Results - causes minimal interference standard TCP significant interference - Significant spare BW throughout the day Background traffic: - Long-lived flows -, rate limiting,, Vegas, Vegas-0 - Ideal: Router prioritization Foreground traffic: Squid proxy trace -, Vegas, RED - On/Off UDP Single bottleneck topology Parameters - spare capacity, number of flows, threshold Metric - average document transfer latency Z. Morley Mao, Winter Z. Morley Mao, Winter

4 1e3 Network Conditions 1e3 Scalability Vegas Document Latency (sec) 10 V0 1 Vegas Router Prio Spare Capacity Document Latency (sec) 10 V0 1 Router Prio Num BG flows causes low interference even when there isn t much spare capacity. Z. Morley Mao, Winter W < 1 allows to scale to any number of background flows Z. Morley Mao, Winter BG Throughput (KB) 8e4 6e4 4e4 2e4 V0 Utilization Vegas Router Prio Num BG flows utilizes 50-80% of spare capacity w/o stealing any bandwidth from FG Z. Morley Mao, Winter Case study 1 : Data Distribution Tivoli Data Exchange system Complexity - 0s of clients - different kinds of networks phone line, cable modem, T1 Problem - tuning data sending rate to reduce interference and maximize utilization Current solution - manual setting for each set of clients Z. Morley Mao, Winter Ping latency (in ms) Case study 1 : Data Distribution Manual tuning point Completion time(in seconds) Austin to London Case study 2: Prefetch- Novel non-intrusive prefetching system [USITS 03] Eliminates network interference using TCP Eliminates server interference using simple monitor Readily deployable - no modifications to HTTP or the network - JavaScript based Self-tuning architecture, end-to-end interference elimination Z. Morley Mao, Winter Z. Morley Mao, Winter

5 Case study 2: Prefetch- Prefetching Case Study Response time Aggressiveness Hand-tuned threshold Aggressive threshold + Self-tuning protocol A self -tuning architecture gives optimal performance for any setting Response time (sec) Cable modem None Cons Aggr Prefetching mode Z. Morley Mao, Winter Z. Morley Mao, Winter Prefetching case study Conclusions Phone line End-to-end strategy can implement simple priorities Response time (sec) Enough usable spare bandwidth out there that can be ly harnessed makes application design easy None Cons Aggr Prefetching mode Z. Morley Mao, Winter Z. Morley Mao, Winter End-to-end WAN Service Availability Limitation of the study Studies how network failures affect WAN service availability Evaluate techniques for improving end-to-end service availability Methodology - Traces: HTTP, traceroute - Develop a model of network unavailability Failure locaiton, duration Bias due to the trace - Trace does not reflect application semantics No model of load, mostly only network effects Not end-to-end Not representative of typical Internet connectivity What if measurement probe failed? Assumption of the adaptation methdology Conclusion: - Caching alone not effective - Need a combination of mobile code, prefetching Z. Morley Mao, Winter Z. Morley Mao, Winter

6 Techniques for improving WAN service availability Project Masking network unavailability - Client side Caching Relaxed consistency, push-updates Prefetching: hoarding, server push Replication Network routing - Re-routing: overlay - Server replication and selection How to effectively combine these techniques? Measurement project Algorithm design Implementation Study of an existing system Z. Morley Mao, Winter Z. Morley Mao, Winter Project ideas Project ideas Internet routing attacks - How to improve the robustness of BGP, OSPF - Can you think of a new attack? Intrusion detection system - Add a new protocol analyzer to Bro Beacon data analysis - Correlating between routing plane and data plane - Study how happy packets are? Internet relationship inference - Based on occurrence of Aspaths per IP address - Based on the overlap of address space between ISPs Measurement tools to get around firewalls - Study why traceroute stops: routing failures vs. firewall blocking - Number of hops behind firewalls - Fire-wall friendly probing Z. Morley Mao, Winter Sensor networking - For patient monitoring Measurement data analysis from open proxy on planet lab - Performance clustering Clustering based on loss, one-way delay, jitter Peer to peer networks - Security issues Network research models - Models for routing research Enhancement/modification to TCP - For BGP - High loss rate, long delay Z. Morley Mao, Winter User-level Internet Path Diagnosis [Mahajan] Tool tulip - Diagnoses reordering, loss, queuing events Internet Approximations: - Out of band measurement probes TTL=limited probes - ICMP timestamp requests to access time at the router Non universal support, about 90% routers - IP identifiers instead of per-flow counters IP-ID field: unique among all packets sent from a machine to the same destination» For IP fragments reassembly Z. Morley Mao, Winter