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 NedevschiJaideep ChandrashekarJunda LiuBruce Nordman Sylvia RatnasamyNina Taft

ICSI & Intel Research Intel Research

UC BerkeleyLBNL

Intel ResearchIntel Research

Presented by: Manikandan Somasundaram

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

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:

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

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

0%

25%

50%

75%

100%

1 3 5 7 9 11 13 15 17 19 21 23

sorted users

off

as leep

active

idle

• 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

0%

25%

50%

75%

100%

1 3 5 7 9 11 13 15 17 19 21 23

sorted users

off

as leep

active

idle

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)

Incoming traffic high even when idle

Home Office

Environment

Pac

kets

/sec

ond

Idle

Active

14

Sleep time when waking for every packet

Transition time ts = 10s

Sorted Users

Frac

tion

of

idle

tim

e us

ers

can

slee

p

Home

Office

Waking for every packet is not enough

15

What kind of solution do we need?

Simplest

Transparent(Default WAKE)

IGNORE orWAKE

IGNORE,WAKE orRESPOND

ComplexProcessing

Non Transparent(Default IGNORE)

for everythingWake:

?

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)• 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

ts = 10s ( )

Sleep 90% of the time

ts = 1min ( )

Sleep 40% of the time

19

Computing half_sleepTransition time

Sleep(% time)

1s 99%

2s 98%

5s 95%

10s 90%

30s 70%

1min 55%

2min 30%

5min 15%

10min 11%

15min 8%

• 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

• Majority of incoming traffic is multicast or broadcast - mostly useless network chatter

Unicast

MulticastBroadcast

Home Office Home Office

INCOMING OUTGOING

21

Deconstructing Broadcast • Traffic volume

• Half_sleep

Can be ignored

Can be handled by simple responses

22

Deconstructing Multicast

Can be handled by simple responses

Can be ignored

• Key offenders (half_sleep)

23

• Key offenders (half_sleep)

Deconstructing Unicast

UDP 1-2minTCP 8-15min

TCP 10-20sUDP 1-2min

24

Outline

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

25

What kind of solution do we need?

Nothing

Transparent(Default WAKE)

IGNORE orWAKE

IGNORE,WAKE orRESPOND

More ComplexProcessing

Non Transparent(Default IGNORE)

Wake: everything else

HSRP, EIGRP,PIM, IPX, LLC, EIGRP, ARP (for others)

Ignore:

Wake: for everything else

sameIgnore:

Respond: ARP, NBNS, SSDP, IGMP, ICMP

Wake:

for everything elseIgnore:

Respond: ARP, NBNS, SSDP, IGMP, ICMP

telnet, ssh, VNC, SMB, NetBios (for me)

for everythingWake:

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 orRespond.Transparent

Ignore, Wake or Respond.Non-transparent

Office

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 implementationSleepyHappy Grumpy Dopey

• Standalone machine on the same LAN

• Implemented in ClickProxy

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 proxy1) “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 proxying1) ignorable (drop) (e.g. router traffic)2) mechanical responses (e.g ARP, NBNS, SSDP, IGMP, echo ICMP)3) require more complex processing

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

% Idle Time

0

10

20

30

40

50

60

70

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

20-4040-60> 60

Second-long bins for inter-packet gaps

% of idle time.

Home

Office98% of the cases, the following packet arrival will be within 3 seconds