1. Identifying and Using Energy Critical Paths Nedeljko Vasić with Dejan Novaković, Satyam Shekhar, Prateek Bhurat, Marco Canini, and Dejan Kostić EPFL, Switzerland Networked Systems Laboratory

2. 2 NETWORK Datacenter DATACENTER NETWORK 20% of total server energy consumption (3 TWh in US in 2006) Networking Energy Several TWh/year for major telcos (Telefonica 4.5 TWh, Verizon 9.9 TWh)

3. Causes of networking energy consumption Network redundancy – Achieving high availability Bandwidth overprovisioning – Tolerate traffic variations (address lack of QoS) 3

4. Typical utilization levels Energy-(un)proportionality 4 0 20 40 60 80 100 0 20 40 60 80 100 Power (% of peak) Utilization (%) Ideal energy-proportionality Existing networking hardware

5. Networking energy outlook More demands will result in further increases – Video streaming, Cloud computing CMOS reaching a plateau in power-efficiency – Cooling costs of new equipment will increase 1 MW for latest Cisco platform, CRS-1 5 Rate of traffic increase > rate in which underlying technologies improve their energy efficiency Power is not limitless (60 Amps per rack)

6. Goal: Energy-Proportional Networked Systems 6 0 20 40 60 80 100 0 20 40 60 80 100 Utilization (%) Goal Power (% of peak) Ideal energy-proportionality

7. Make all devices energy-proportional? 7 Utilization (%) Power (% of peak) Ideal energy-proportionality Performance penalties Always-on components

8. 8 Dynamically match resources to the demand  make the network energy-proportional Sleeping saves energy Network-wide energy-proportionality

9. Routing table computation Goal: The minimal set of network elements (w.r.t. power) that will satisfy the current demands Routing that minimizes energy consumption – Multi-commodity flow problem, but with additional constraints for energy objective: Links + routers (switches) powered on/stand by – Problem is computationally intensive – Heuristics take several minutes for small topologies When traffic demand changes, optimal routing changes! 9

10. How often is recomputation needed? 10 [Geant2 - European academic network, 15-day trace]

11. How often is recomputation needed? 11 B C A D Time 15 min.

12. How often is recomputation needed? 12 Routing table recomputed 3-4 times per hour! (state-of-the-art) [Geant2 - European academic network, 15-day trace]

13. Long computation time might lead to energy waste or congestion Adjusting routing upon each change in traffic patterns often leads to oscillations Network operators would like to base their designs on longer time scales 13 Issues with recomputation

14. Can we precompute routing configurations? 14 B C A D Time 15 min

15. Can we precompute routing configurations? 15 Too many routing configurations Fraction of time an energy-optimal routing configuration is used (Geant2 trace) One routing configuration used 60% of the time

16. Energy Critical Paths 16 Just a few precomputed paths offer near-optimal energy savings

17. REsPoNse ( Responsive Energy-Proportional Networks ) 17 Energy-Aware Traffic Engineering Runtime Traffic Measurement [COMSNETS ‘09] Computing Energy-Critical Paths Traffic Analysis Online components Offline components Service-Level Objectives

18. REsPoNse Always-on paths provide a routing that can carry low to medium amounts of traffic at the lowest energy consumption On-demand paths start carrying traffic when the load is beyond the capacity offered by the always-on paths Failover paths are designed to minimize the impact of single failures 18 REsPoNseREsPoNse-latREsPoNse-heuristicREsPoNse-ospf

19. REsPoNseTE in action Dest Src A B C D Online effort to shift traffic to (in)activate on-demand paths Intermediate routers mark packets with link load Edge routers collect load info only on alternative paths 19 Load(AO) > Tr TE

20. Evaluation Questions How energy-proportional is REsPoNse? – ISP topologies – Datacenter networks How quick is REsPoNseTE in shifting traffic? What is the impact of traffic aggregation on application performance? 20

21. Responsiveness/Energy-Proportionality (Geant) 21 Replayed a 15-day trace 2 power models –Today –Future (static power is significantly reduced) REsPoNse saves 30% - 45% with adding only 1 carefully precomputed routing table Power (% of original) 100 80 60 40 20 Demands (GBps) 5432154321

22. Impact on application performance 22 Application performance and e2e latency under REsPoNse is comparable to OSPF at both low and high utilization levels. Live Modelnet experiment with P2P-VoD (BulletMedia [IPTV ‘07]) REsPoNse OSPF REsPoNse OSPF low utilization high utilization REsPoNse OSPF low utilization Percentage (%) 100 95 90 85 80 Block retr. latency (s) 1.5 1 0.5 0

23. 23 Conclusion REsPoNse Key idea: hybrid offline/online approach based on existence of energy critical paths Properties Stable Incrementally deployable Responsive REsPoNse enables power/cooling for the common case