300 likes | 380 Views
One More Bit Is Enough. Yong Xia, RPI Lakshminarayanan Subramanian, UCB Ion Stoica, UCB Shivkumar Kalyanaraman, RPI SIGCOMM’05, August 22-26, 2005, Philadelphia, Pennsylvania, USA. Goal.
E N D
One More Bit Is Enough Yong Xia, RPI Lakshminarayanan Subramanian, UCB Ion Stoica, UCB Shivkumar Kalyanaraman, RPI SIGCOMM’05, August 22-26, 2005, Philadelphia, Pennsylvania, USA
Goal • Achieve fair bandwidth allocation and high utilization, and minimize packet loss in high bandwidth-delay product (BDP) network • TCP ? • TCP + AQM / ECN? • XCP ? VCP 2
congestion congestion avoidance slow! slow start Additive Increase (AI) Why TCP does not scale? • TCP uses duplicate ACK or timeout: no degree of congestion and instability congestion window Multiplicative Decrease (MD) time • AI with a fixed step-size can be very slow for large bandwidth VCP 3
bottleneck utilization bottleneck utilization 100% 100% TCP TCP 70% 50% bandwidth (Mbps) round-trip delay (ms) TCPdoes not perform well in high b/w VCP 4
XCP scales C spare bandwidth DATA x ACK rate sender router receiver • But, XCP needs multiple bits (128 bits in its current IETF draft) to carry the congestion-related information from/to network VCP 5
Goal Design a TCP-like scheme that: • requires a small amount of congestion information (e.g., 2 bits) • scales across a wide range of network scenarios VCP 6
General idea degree of explicit information XCP: multiple bits, report spare bandwidth VCP: two bits, low-load, high-load and overload ECN: one bit, underload and overload TCP: no explicit feedback, relay on duplicate ACKand timeout
range of interest scale-free region code control load factor overload (11) Multiplicative Decrease (MD) 1 high-load (10) Additive Increase (AI) (01) low-load Multiplicative Increase (MI) 0 traffic rate link capacity x 2-bit ECN 2-bit ECN sender router receiver ACK Variable-structure congestion Control Protocol (VCP) • Routerssignalthelevel of congestion • End-hosts adapt the control algorithm accordingly VCP 8
ECN doesn’t differentiate between low-load and high-load regions TCP VCP AQM/ECN load factor (1) (11) 1 high-load (10) Additive Increase (AI) Additive Increase (AI) underload (0) (01) low-load Multiplicative Increase (MI) 0 x 2-bit ECN 1-bit ECN sender router receiver ACK ACK VCP vs. ECN region code control overload Multiplicative Decrease (MD) VCP 9
TCP+RED/ECN utilization cwnd time (sec) VCP vs. ECN VCP utilization cwnd time (sec) VCP 10
router end-host overload high-load fairness control AIMD low-load efficiency control MI VCP key ideas and properties • Use network link load factor as the congestion signal • Decouple efficiencyandfairness controls in different load regions • Achieve high efficiency, low loss, and small queue • Fairness model is similar to TCP: • Long flows get lower bandwidth than in XCP (proportional vs. max-min fairness) • Fairness convergence much slower than XCP VCP 11
control load region code overload (11) Multiplicative Decrease (MD) high-load Additive Increase (AI) (10) (01) low-load Multiplicative Increase (MI) Major design issues • At the router • How to measure and encode the load factor? • At the end-host • When to switch from MI to AI? • What MI/AI/MD parameters to use? • How to handle heterogeneous RTTs? VCP 12
t= 200ms most rtt demand load_factor = capacity arrival_traffic + queue_size = Design issue #1: measuring and encoding load factor • Calculate the link load factor link_bandwidth * t • The load factor is quantized and encoded into the two ECN bits VCP 13
overload high-load AIMD low-load MI Design issue #2: setting MI/AI/MD parameters (, , ) VCP 14
= = 0.875 *= safety margin 80% 20% = 80% Design issue #2: setting MI/AI/MD parameters (, , ) load factor MD 100% AI 1.0 TCP: = 1.0 VCP: = 0.06 STCP: = 0.01 k (1 *) / * where k = 0.25 (for stability) MI 0% VCP 15
Design issue #3: Handling RTT heterogeneity for MI/AI VCP 16
150Mbps, 80ms, 50 forward flows and 50 reverse flows VCP scales across b/w, rtt, num flows • Evaluation using extensive ns2 simulations VCP 17
Impact of bottleneck capacity vary link capacity from 100Kbps to 5Gbps high utilization, gap comparing toXCP at most 7% at extremely low capacities alpha = 1 is too large for such low capacity
Impact of feedback delay average queue < 5%maximal queue < 15% fix bottleneck capacity at 150Mbps, vary round-trip propagation delay from 1ms to 1500ms utilization > 90% no packet loss lower utilization due to comparable smallmeasurement interval, i.e. tp = 200ms << RTT
Impact of number of long-lived flows small queue length, even outperform XCP increase the # forward FTP flows high utilization zero packet drop
Impact of short-lived traffic small queue length arrive according to Poisson process, avg. arrival rate varying from 1/s to 1k/s,transfer size obeys Pareto distribution with avg. 30 packets high utilization zero packet drop
Multiple bottlenecks < 0.2% buffer size average queue length typical parking-lot topology as good as single-bottleneck scenarios zero packet drop
Fairness • same RTT • small RTT difference • huge RTT difference even distribution among all flows in case (a) and (b) fairness discrepancy due to high value of MI and AI, whose value is bound in implementation to prevent burst
Convergence behavior high utilization during the whole period introduce 5 flows one after another use router buffer size to scale queue length axis; low queue length during the whole period
Sudden demand change high utilization 150 flows join at 80s and leave at 160s remain much lower than full size
Conclusions • With a few minor changes over TCP+AQM/ECN, VCP is able to approximate the performance of XCP • High efficiency • Low persistent bottleneck queue • Negligible congestion-caused packet loss • Reasonable (i.e., TCP-like) fairness VCP 26
VCP comparisons • Compared to TCP+AQM/ECN • Same architecture (end-hosts control, routers signal) • Router congestion detection: queue-based load-based • Router congestion signaling: 1-bit 2-bit ECN • End-host adapts (MI/AI/MD) according to the ECN feedback • End-host scales its MI/AI parameters with its RTT • Compared to XCP • Decouple efficiency/fairness control across load regions • Functionality primarily placed at end-hosts, not in routers VCP 27
THE END VCP 28
Remark Modified from www.ecse.rpi.edu/Homepages/ shivkuma/research/papers/vcp05.ppt