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

2. 2 Sergiu Nedevschi Jaideep Chandrashekar Junda Liu Bruce Nordman Sylvia Ratnasamy Nina Taft ICSI & Intel Research Intel Research UC Berkeley LBNL Intel Research Presented by: Manikandan Somasundaram

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

4. 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. 5 Contributions Answer the following: 1.Is the problem worth solving? – Potential energy savings 2.What is the design space? – Tradeoffs between design complexity & savings 3.What protocols should be handled and how? – Wake, Respond (proxy) and ignore Propose & prototype an extensible proxy architecture

6. 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. 7 Outline Potential and Need for Proxying Proxy Design Space Deconstructing Traffic Proxy Architecture & Prototype

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

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

10. 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. 11 Squandered energy Given the following: – 170 million desktop PCs in the US 60TWh/year wasted ( ~ 6 billion dollars)

12. 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. 13 Traffic volume (incoming packets/second) Incoming traffic high even when idle Home Office Environment Packets/second Idle Active

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

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

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

17. 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. 18 Half-time sleep ( ts_50) 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 t s : If we sleep well even for large ts: P is sleep friendly If we sleep little even for small ts: P is sleep unfriendly t s = 10s ( )Sleep 90% of the time t s = 1min ( ) Sleep 40% of the time

19. 19 Computing half_sleep Transition time Sleep (% time) 1s99% 2s98% 5s95% 10s90% 30s70% 1min55% 2min30% 5min15% 10min11% 15min8% 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. 20 Traffic Composition Majority of incoming traffic is multicast or broadcast - mostly useless network chatter Unicast Multicast Broadcast Home Office HomeOffice INCOMINGOUTGOING

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

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

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

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

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

26. 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 Ignore, Wake or Respond. Transparent Ignore, Wake or Respond. Non-transparent Office Home

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

28. 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. 29 Example proxy implementation Standalone machine on the same LAN Implemented in Click Proxy

30. 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. 31 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. 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. 33 Thank you!!!

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

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

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