Skilled in the Art of Being Idle: Reducing Energy Waste in Networked Systems

1. Skilled in the Art of Being Idle:Reducing Energy Waste in Networked Systems

2. Skilled in the Art of Being Idle:Reducing Energy Waste in Networked Systems Sergiu Nedevschi Jaideep Chandrashekar Junda Liu Bruce Nordman Sylvia Ratnasamy Nina Taft ICSI & Intel Research Intel Research UC Berkeley LBNL Intel Research Intel Research Presented by: Manikandan Somasundaram

3. Motivation Systems draw significant power when idle Power draw Remain powered on: + maintains connectivity - wastes power (> 50W ) Go to sleep: + saves power (< 5W) - systems lose “network presence” • remote access • scheduled tasks • background tasks ||

4. Old Proposals • Wake-on-LAN/WLAN/pattern (“magic packets”) • Network Connection Proxy (NCP) • So far, little evaluation of • potential for energy savings • exploration of the solution design space

5. Contributions • Answer the following: • Is the problem worth solving? • Potential energy savings • What is the design space? • Tradeoffs between design complexity & savings • What protocols should be handled and how? • Wake, Respond (proxy) and ignore • Propose & prototype an extensible proxy architecture

6. Trace information • Collected traces of 250 Intel host computers • 90% laptops, 10% desktops • In office (Intel) & at home • Over 4 weeks (some less), spring 2007 • Traces contain: • Packet traces; flow information • Logs of keyboard & mouse activity, power state, etc. • Used to infer when machines are idle

7. Outline • Potential and Need for Proxying • Proxy Design Space • Deconstructing Traffic • Proxy Architecture & Prototype

8. Outline • Potential and Need for Proxying • Proxy Design Space • Deconstructing Traffic • Proxy Architecture & Prototype

9. % time spent in different states • Desktops (< 10% of machines) On averages, desktops are idle > 50% of time

10. % energy spent in different states • Assume desktops and typical power draws • 2W powered down, 3W asleep, 80W idle, 90W active Desktops waste > 60% of energy while idle

11. Squandered energy • Given the following: • 170 million desktop PCs in the US 60TWh/year wasted ( ~ 6 billion dollars)

12. Do we need proxying? … or can we simply wake up for every packet? • Depends on: • Time ts that it takes to wake up and then go back to sleep • Volume of incoming traffic • Traffic pattern (inter-packet gaps)

13. Traffic volume (incoming packets/second) Idle Active Packets/second Office Home Environment Incoming traffic high even when idle

14. Sleep time when waking for every packet Home Office Fraction of idle time users can sleep Sorted Users Transition time ts = 10s Waking for every packet is not enough

15. What kind of solution do we need? Wake: for everything Transparent (Default WAKE) Non Transparent (Default IGNORE) Simplest IGNORE or WAKE ? IGNORE, WAKE or RESPOND Complex Processing

16. Outline • Potential and Need for Proxying • Deconstructing Traffic • Proxy Design Space • Proxy Architecture & Prototype

17. Deconstructing by protocol • Find protocols most responsible for poor sleep • “key offenders” • For each offender, find their purpose, and how they can be handled • ignore, respond, wake • Metrics for key offenders • Volume ( # packets) • Half-time sleep (ts_50)

18. Half-time sleep (ts_50) Sleep 40% of the time ts = 1min ( ) ts = 10s ( ) Sleep 90% of the time • ts_50(P): Measures protocol P’s role in preventing sleep • How much can we sleep when waking only for protocol P ? • Depends on the transition time ts: • If we sleep well even for large ts: P is sleep friendly • If we sleep little even for small ts: P is sleep unfriendly

19. Computing half_sleep • Compute sleep for discrete transition times • 1s … 15min • e.g.ts_50 = 5s means protocol P wakes the machine up every 10s ts_50 = largest transition time ts for which sleep > 50% 1min < ts_50 < 2min

20. Traffic Composition Unicast Multicast Broadcast Home Home Office Office INCOMING OUTGOING • Majority of incoming traffic is multicast or broadcast - mostly useless network chatter

21. Deconstructing Broadcast Can be handled by simple responses Can be ignored • Traffic volume • Half_sleep

22. Deconstructing Multicast Can be handled by simple responses Can be ignored • Key offenders (half_sleep)

23. Deconstructing Unicast • Key offenders (half_sleep) TCP 10-20s UDP 1-2min UDP 1-2min TCP 8-15min

24. Outline • Potential and Need for Proxying • Deconstructing Traffic • Proxy Design Space • Proxy Architecture & Prototype

25. What kind of solution do we need? Wake: for everything Wake: telnet, ssh, VNC, SMB, NetBios (for me) Respond: ARP, NBNS, SSDP, IGMP, ICMP ARP, NBNS, SSDP, IGMP, ICMP Respond: Ignore: same HSRP, EIGRP,PIM, IPX, LLC, EIGRP, ARP (for others) Ignore: Wake: for everything else for everything else Ignore: Wake: everything else Transparent (Default WAKE) Non Transparent (Default IGNORE) Nothing IGNORE or WAKE IGNORE, WAKE or RESPOND More Complex Processing

26. Evaluation of Sample Proxies Non-transparent proxies (even simple ones) are very efficient Transparent proxies could be good for home, not office Wake for everything Ignore or Wake. Transparent Office Ignore, Wake or Respond. Transparent Ignore, Wake or Respond. Non-transparent Home

27. Outline • Potential and Need for Proxying • Deconstructing Traffic • Proxy Design Space • Proxy Architecture & Prototype

28. General Proxy Architecture • A list of rules: (trigger, action) • Triggers (incoming packet, proxy state) • Actions: • drop • wake (timeout) • respond (template, state) • redirect (handle) • This architecture is agnostic to where proxy runs • e.g. network card, server running on same LAN, router, etc.

29. Example proxy implementation • Standalone machine • on the same LAN • Implemented in Click Proxy

30. Proxy Prototype • Simple (non-transparent), but extensible: (TCP SYN, Wake), (Netbios Name Query for me, Wake), (ARP for me, Respond), (ICMP echo, Respond), (Other, Ignore) • No explicit state transfer • Learns state by sniffing traffic • (Netbios names  IP), (IP  ETH) • Advantages: • No modifications to end systems • Separate network product

31. Conclusions • Conclusions • Waste in networked systems is a real problem (6 billion/year) • Need proxying to solve it • Low hanging fruit • Multiple design options, may depend on usage environments

32. Discussion • How to build clean slate energy friendly protocols? • In this work proxies handle existing protocols • It would be nice if the new protocols do not require proxying at all or don’t need to augment the proxy every time a protocol is added. • How about application involvement? • Application being energy friendly • Coordination across protocols/applications.

33. Thank you!!!

34. Protocol Classification • Need to proxy • “don’t wake” protocols (e.g. IGMP, PIM, ARP) • “don’t ignore” protocols (e.g DHCP lease, NBNS queries for me, ARP queries for me) • policy-dependent • Method of proxying • ignorable (drop) (e.g. router traffic) • mechanical responses (e.g ARP, NBNS, SSDP, IGMP, echo ICMP) • require more complex processing

35. How much does dealing with chatter help? Broadcast & multicast mostly responsible for poor sleep • Chatter = most of broadcast and multicast • Deal with = Either ignore or proxy (offload)

36. % Idle Time 98% of the cases, the following packet arrival will be within 3 seconds