Buffers: How we fell in love with them, and why we need a divorce Hot Interconnects, Stanford 2004 Nick McKeown High Performance Networking Group Stanford.

Slides:



Advertisements
Similar presentations
EE384Y: Packet Switch Architectures
Advertisements

Introducing optical switching into the network
1 Understanding Buffer Size Requirements in a Router Thanks to Nick McKeown and John Lockwood for numerous slides.
Router Buffer Sizing and Reliability Challenges in Multicast Aditya Akella 02/28.
Lecture 3  A round up of the most important basics I haven’t covered yet.  A round up of some of the (many) things I am missing out of this course (ATM,
Advanced Computer Networking Congestion Control for High Bandwidth-Delay Product Environments (XCP Algorithm) 1.
Confused, Timid and Unstable: Picking a Video Rate is Hard Te-Yuan (TY) Huang Stanford University Nov 15 th, 2012 Joint work with Nikhil Handigol, Brandon.
The Tension Between High Video Rate and No Rebuffering Te-Yuan (TY) Huang Stanford University IRTF Open 87 July 30th, 2013 Joint work Prof.
XCP: Congestion Control for High Bandwidth-Delay Product Network Dina Katabi, Mark Handley and Charlie Rohrs Presented by Ao-Jan Su.
Sizing Router Buffers Guido Appenzeller Isaac Keslassy Nick McKeown Stanford University.
Router Architecture : Building high-performance routers Ian Pratt
Active Queue Management. Fundamental problem: Queues and TCP Queues –Queues are to absorb bursts of packets. –They are required for statistical multiplexing.
Designing Networks with Little or No Buffers or Can Gulliver Survive in Lilliput? Yashar Ganjali High Performance Networking Group Stanford University.
High Performance All-Optical Networks with Small Buffers Yashar Ganjali High Performance Networking Group Stanford University
Buffer Sizing for Congested Internet Links Chi Yin Cheung Cs 395 Advanced Networking.
High Performance Networking with Little or No Buffers Yashar Ganjali High Performance Networking Group Stanford University
1 Circuit Switching in the Core OpenArch April 5 th 2003 Nick McKeown Professor of Electrical Engineering and Computer Science, Stanford University
1 Architectural Results in the Optical Router Project Da Chuang, Isaac Keslassy, Nick McKeown High Performance Networking Group
Network Processors and their memory Network Processor Workshop, Madrid 2004 Nick McKeown Departments of Electrical Engineering and Computer Science, Stanford.
High Performance Networking with Little or No Buffers Yashar Ganjali on behalf of Prof. Nick McKeown High Performance Networking Group Stanford University.
Sizing Router Buffers (Summary)
Sizing Router Buffers Nick McKeown Guido Appenzeller & Isaac Keslassy SNRC Review May 27 th, 2004.
Modeling TCP in Small-Buffer Networks
EE 122: Router Design Kevin Lai September 25, 2002.
The Effect of Router Buffer Size on HighSpeed TCP Performance Dhiman Barman Joint work with Georgios Smaragdakis and Ibrahim Matta.
048866: Packet Switch Architectures Dr. Isaac Keslassy Electrical Engineering, Technion Introduction.
Reducing the Buffer Size in Backbone Routers Yashar Ganjali High Performance Networking Group Stanford University February 23, 2005
1 Emulating AQM from End Hosts Presenters: Syed Zaidi Ivor Rodrigues.
Nick McKeown 1 Memory for High Performance Internet Routers Micron February 12 th 2003 Nick McKeown Professor of Electrical Engineering and Computer Science,
Isaac Keslassy (Technion) Guido Appenzeller & Nick McKeown (Stanford)
Stanford University August 22, 2001 TCP Switching: Exposing Circuits to IP Pablo Molinero-Fernández Nick McKeown Stanford University.
L13: Sharing in network systems Dina Katabi Spring Some slides are from lectures by Nick Mckeown, Ion Stoica, Frans.
Congestion Control for High Bandwidth-delay Product Networks Dina Katabi, Mark Handley, Charlie Rohrs.
Routers with Small Buffers Yashar Ganjali High Performance Networking Group Stanford University
1 A State Feedback Control Approach to Stabilizing Queues for ECN- Enabled TCP Connections Yuan Gao and Jennifer Hou IEEE INFOCOM 2003, San Francisco,
Can Google Route? Building a High-Speed Switch from Commodity Hardware Guido Appenzeller, Matthew Holliman Q2/2002.
Second year review Resource Pooling Damon Wischik, UCL.
Buffer requirements for TCP: queueing theory & synchronization analysis Gaurav RainaDamon Wischik CambridgeUCL.
Open Issues in Buffer Sizing Amogh Dhamdhere Constantine Dovrolis College of Computing Georgia Tech.
Courtesy: Nick McKeown, Stanford 1 TCP Congestion Control Tahir Azim.
CS144 An Introduction to Computer Networks
Experiences in Design and Implementation of a High Performance Transport Protocol Yunhong Gu, Xinwei Hong, and Robert L. Grossman National Center for Data.
Congestion models for bursty TCP traffic Damon Wischik + Mark Handley University College London DARPA grant W911NF
How Emerging Optical Technologies will affect the Future Internet NSF Meeting, 5 Dec, 2005 Nick McKeown Stanford University
1 - CS7701 – Fall 2004 Review of: Sizing Router Buffers Paper by: – Guido Appenzeller (Stanford) – Isaac Keslassy (Stanford) – Nick McKeown (Stanford)
Sizing Router Buffers How much packet buffers does a router need? C Router Source Destination 2T The current “Rule of Thumb” A router needs a buffer size:
ACN: RED paper1 Random Early Detection Gateways for Congestion Avoidance Sally Floyd and Van Jacobson, IEEE Transactions on Networking, Vol.1, No. 4, (Aug.
Designing Packet Buffers for Internet Routers Friday, October 23, 2015 Nick McKeown Professor of Electrical Engineering and Computer Science, Stanford.
High-speed TCP  FAST TCP: motivation, architecture, algorithms, performance (by Cheng Jin, David X. Wei and Steven H. Low)  Modifying TCP's Congestion.
Winter 2006EE384x1 EE384x: Packet Switch Architectures I Parallel Packet Buffers Nick McKeown Professor of Electrical Engineering and Computer Science,
Requirements for Simulation and Modeling Tools Sally Floyd NSF Workshop August 2005.
Nick McKeown1 Building Fast Packet Buffers From Slow Memory CIS Roundtable May 2002 Nick McKeown Professor of Electrical Engineering and Computer Science,
Analysis of Buffer Size in Core Routers by Arthur Dick Supervisor Anirban Mahanti.
1 SIGCOMM ’ 03 Low-Rate TCP-Targeted Denial of Service Attacks A. Kuzmanovic and E. W. Knightly Rice University Reviewed by Haoyu Song 9/25/2003.
Performance Engineering E2EpiPEs and FastTCP Internet2 member meeting - Indianapolis World Telecom Geneva October 15, 2003
Winter 2008CS244a Handout 71 CS244a: An Introduction to Computer Networks Handout 7: Congestion Control Nick McKeown Professor of Electrical Engineering.
Chapter 11.4 END-TO-END ISSUES. Optical Internet Optical technology Protocol translates availability of gigabit bandwidth in user-perceived QoS.
TCP continued. Discussion – TCP Throughput TCP will most likely generate the saw tooth type of traffic. – A rough estimate is that the congestion window.
TCP transfers over high latency/bandwidth networks & Grid DT Measurements session PFLDnet February 3- 4, 2003 CERN, Geneva, Switzerland Sylvain Ravot
1 How scalable is the capacity of (electronic) IP routers? Nick McKeown Professor of Electrical Engineering and Computer Science, Stanford University
TCP Traffic Characteristics—Deep buffer Switch
1 Flow & Congestion Control Some slides are from lectures by Nick Mckeown, Ion Stoica, Frans Kaashoek, Hari Balakrishnan, and Sam Madden Prof. Dina Katabi.
Networks with Very Small Buffers Yashar Ganjali, Guido Appenzeller, High Performance Networking Group Prof. Ashish Goel, Prof. Tim Roughgarden, Prof. Nick.
Sachin Katti, CS244 Slides courtesy: Nick McKeown
Understanding Buffer Size Requirements in a Router
Open Issues in Router Buffer Sizing
Review: Statistical Multiplexing
Techniques and problems for
Routers with Very Small Buffers
Presentation transcript:

Buffers: How we fell in love with them, and why we need a divorce Hot Interconnects, Stanford 2004 Nick McKeown High Performance Networking Group Stanford University

2 Which would you choose? DSL Router 1DSL Router 2 $50 4 x 10/100 Ethernet 1.5Mb/s DSL connection 1Mbit of packet buffer $55 4 x 10/100 Ethernet 1.5Mb/s DSL connection 4Mbit of packet buffer

3 Network religion Bigger buffers are better

4 Outline  How we fell in love with buffers  Why bigger is not better  Network users don’t like buffers  Network operators don’t like buffers  Router architects don’t like buffers  We don’t need big buffers  We’d often be better off with smaller buffers  Some examples  How small could we make the buffers?

5 What we learn in school  Packet switching is good  Long haul links are expensive  Statistical multiplexing allows efficient sharing of long haul links  Packet switching requires buffers  Packet loss is bad  Use big buffers  Luckily, big buffers are cheap

6 Statistical Multiplexing Observations 1.The bigger the buffer, the lower the packet loss. 2.If the buffer never goes empty, the outgoing line is busy 100% of the time.

7 What we learn in school 1. Queueing Theory 1 1  M/M/1 X Buffer size Loss rate Observations 1.Can pick buffer size for a given loss rate. 2.Loss rate falls fast with increasing buffer size. 3.Bigger is better.

8 What we learn in school 2. Large Deviations 1 1  X Buffer size Loss rate Observations 1.Arrival and service rates determine  2.Can find bound on loss rate. 3.Bigger is better. [Broad class]

9 What we learn in school 3. Networks of queues Queueing Theory: Jackson networks, BCMP networks, … Large Deviations: Additivity of effective bandwidths, decoupling bandwidth, … Observations 1.Can find bound on loss rate. 2.Bigger is better.

10 What we learn in school  Moore’s Law: Memory is plentiful and halves in price every 18 months.  1Gbit memory holds 500k packets and costs $25.  Conclusion:  Make buffers big.  Choose the $55 DSL router.

11 Why bigger isn’t better  Network users don’t like buffers  Network operators don’t like buffers  Router architects don’t like buffers  We don’t need big buffers  We’d often be better off with smaller ones

12 Example  10Gb/s linecard  Rule-of-thumb: 250ms of buffering  Requires 300Mbytes of buffering.  Read and write 40 byte packet every 32ns.  Memory technologies  SRAM: require 80 devices, 1kW, $2000.  DRAM: require 4 devices, but too slow.  Problem gets harder at 40Gb/s

13 Sizing buffers Packets are generated by a closed-loop feedback system  95% of traffic is TCP: End-to-end window-based flow control  Queues with closed-loop source behave very differently  TCP requires packet loss. Loss is not bad.  Throughput is a better metric.

14 Review: TCP Congestion Control Only W packets may be outstanding Rule for adjusting W  If an ACK is received: W ← W+1/W  If a packet is lost:W ← W/2 SourceDest t Window size

15 Review: TCP Congestion Control Only W packets may be outstanding Rule for adjusting W  If an ACK is received: W ← W+1/W  If a packet is lost:W ← W/2

16 Some Examples Example 1: Make backbone router buffers 99% smaller! Example 2: Make access router buffers much smaller too! Example 3: Heck, things aren’t so bad with no buffers at all.

17 Backbone router buffers  Universally applied rule-of-thumb:  A router needs a buffer size: 2T is the two-way propagation delay C is capacity of bottleneck link  Context  Mandated in backbone and edge routers.  Appears in RFPs and IETF architectural guidelines..  Usually referenced to Villamizar and Song: “High Performance TCP in ANSNET”, CCR,  Already known by inventors of TCP [Van Jacobson, 1988]  Has major consequences for router design C Router Source Destination 2T

18 Backbone router buffers  It turns out that  The rule of thumb is wrong for a core routers today  Required buffer is instead of  Where does the rule of thumb come from? (Answer: TCP)

19 Single TCP Flow Router with large enough buffers for full link utilization

20 Single TCP Flow Router with large enough buffers for full link utilization Observations  Sending rate is constant  If buffer doesn’t go empty when window size halves, then we have 100% throughput. t Window size RTT It follows that

21 Buffer = rule of thumb

22 Over-buffered Link

23 Under-buffered Link

24 Rule-of-thumb  Rule-of-thumb makes sense for one flow  Typical backbone link has > 20,000 flows  Does the rule-of-thumb still hold?  Answer:  If flows are perfectly synchronized, then Yes.  If flows are desynchronized then No.

25 If flows are synchronized  Aggregate window has same dynamics  Therefore buffer occupancy has same dynamics  Rule-of-thumb still holds. t

26 If flows are not synchronized Probability Distribution B 0 Buffer Size

27 Quantitative Model  Model congestion window as random variable  If congestion windows are independent, central limit theorem tells us  Thus as n increases, buffer size should decrease

28 Required buffer size Simulation

29 Short Flows  So far we were assuming a congested router with long flows in congestion avoidance mode.  What about flows in slow start?  Do buffer requirements differ?  Answer: Yes, however:  Required buffer in such cases is independent of line speed and RTT (same for 1Mbit/s or 40 Gbit/s)  In mixes of flows, long flows drive buffer requirements Short flow result relevant for uncongested routers

30 Average Queue length

31 Queue Distribution  Large-deviation estimate of queue distribution b P(Q > b) Buffer B Packet Loss

32 Short Flow Summary  Buffer requirements for short flows  Independent of line speed and RTT  Only depends on load and burst size distribution  Example - for bursts of up to size 16 at load 0.8 For 1% loss probability B = 115 Packets For 0.01% loss probability B = 230 packets etc. Bursts of size 12 is maximum for Windows XP  In mixes of flows, long flows dominate buffer requirements

33 Experimental Evaluation  Simulation with ns2  Over 10,000 simulations that cover range of settings Simulation time 30s to 5 minutes Bandwidth 10 Mb/s - 1 Gb/s Latency 20ms -250 ms,  Physical router  Cisco GSR with OC3 line card  In collaboration with University of Wisconsin  Operational Networks  Stanford University  Internet 2

34 Long Flows - Utilization Small Buffers are sufficient - OC3 Line, ~100ms RTT 99.9% 98.0% 99.5% 2×2×

35 Long Flows – Utilization Model vs. ns2 vs. Physical Router GSR 12000, OC3 Line Card TCP Flows Router BufferLink Utilization PktsRAMModelSimExp x 1 x 2 x 3 x Mb 2Mb 4Mb 8Mb 96.9% 99.9% 100% 94.7% 99.3% 99.9% 99.8% 94.9% 98.1% 99.8% 99.7% x 1 x 2 x 3 x kb 1Mb 2Mb 4Mb 99.7% 100% 99.2% 99.8% 100% 99.5% 100% 99.9%

36 Operational Networks TCP Flows Router Buffer Link Utilization PktsModelExp x 1.2 x 1.5 x >>2 x % 100% 97.4% 97.6% 98.5% 99.9% 1. Stanford University Dorm Traffic 20Mb/s 2. Internet2 10Gb/s link, Indianapolis  Kansas City  Cut buffers from 1 second to 5ms (99.5%)  Measured loss: <  Even for 6Gb/s transfers from CERN to SLAC.

37 Impact on Router Design  10Gb/s linecard with 200,000 x 56kb/s flows  Rule-of-thumb: Buffer = 2.5Gbits Requires external, slow DRAM  Becomes: Buffer = 6Mbits Can use on-chip, fast SRAM Completion time halved for short-flows  40Gb/s linecard with 40,000 x 1Mb/s flows  Rule-of-thumb: Buffer = 10Gbits  Becomes: Buffer = 50Mbits

38 Some Examples Example 1: Make backbone router buffers 99% smaller! Example 2: Make access router buffers much smaller too! Example 3: Heck, things aren’t so bad with no buffers at all.

39 Access routers have too much buffering Client DSL router 1 Long file transfer 2 Quick download 300kb/s Ever noticed the following?  Even with the long file transfer, shouldn’t the quick download take as long as it would over a 150kb/s link?  Why does it always seem to take much longer?

40 Access routers have too much buffering Client DSL router 1 Long file transfer 2 Quick download (14 packets) 300kb/s < 0.5 seconds syn 2 0.1s 4 8 Pkts sent

41 Buffer Size t Access routers have too much buffering Client DSL router 1 Long file transfer 2 Quick download (14 packets) W max >1.5s W max = 64kbytes for Linux > 1.5 seconds 300kb/s About 5 seconds! 10x increase. syn 2 >1.5s 4 8 Pkts sent 1 >1.5s

42 Access routers have too much buffering Observations 1. With less buffering:  Downloads would complete faster  Long transfers would be unaffected 2. Because the access router is the bottleneck, packets aren’t buffered in the core.  We could reduce or remove the core buffers

43 Some Examples Example 1: Make backbone router buffers 99% smaller! Example 2: Make access router buffers much smaller too! Example 3: Heck, things aren’t so bad with no buffers at all.

44 TCP with no buffers Utilization of bottleneck link = 75%

45 Summary  Buffering and queueing delay is everything  We don’t really understand buffer sizing in the Internet…  …We need more research. Many thanks to Guido Appenzeller at Stanford. New Flash expert. For more details, see our Sigcomm 2004 paper available at:

46 How small can buffers be?  Imagine you want to build an all-optical router for a backbone network  It’s very hard to build optical buffers…maybe 5-10 packets in delay lines?

47 LASOR Project  DARPA funded since 2004  Partners: UCSB, Cisco, JDSU, Calient, Agility, Stanford  Program: Building high capacity all-optical router with 40Gb/s interfaces  Problem:  If you can design the routing mechanism, packet scheduling, and congestion control, then how small can we make the buffers?

48 What if…  M/M/1 1 1 X  = 50%, EX = 1 packet  = 75%, EX = 3 packets  = 50%, P[X>10] <  = 75%, P[X>10] < 0.06 Theory (benign conditions) Practice Typical OC192 router linecard buffers over 1,000,000 packets What if we randomize launch times and paths, so traffic looks Poisson…?