Transcript Skilled in the Art of Being Idle

Skilled in the Art of Being Idle:
Reducing Energy Waste
in Networked Systems
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
2
Motivation
Systems draw significant power when idle
Power draw
Go to sleep:
+ saves power (< 5W)
-
||
Remain powered on:
+ maintains connectivity
- wastes power (> 50W )
systems lose “network presence”
– remote access
– scheduled tasks
– background tasks
3
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
4
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
5
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
6
Outline
•
•
•
•
Potential and Need for Proxying
Proxy Design Space
Deconstructing Traffic
Proxy Architecture & Prototype
7
Outline
•
•
•
•
Potential and Need for Proxying
Proxy Design Space
Deconstructing Traffic
Proxy Architecture & Prototype
8
% time spent in different states
• Desktops (< 10% of machines)
100%
75%
off
asleep
50%
active
idle
25%
0%
1
3
5
7
9
11
15
13
17
19
21
23
sorted users
On averages, desktops are idle > 50% of time
9
% energy spent in different states
• Assume desktops and typical power draws
– 2W powered down, 3W asleep, 80W idle, 90W active
100%
75%
off
asleep
50%
active
idle
25%
0%
1
3
5
7
9
11
13
15
17
19
21
23
sorted users
Desktops waste > 60% of energy while idle
10
Squandered energy
• Given the following:
– 170 million desktop PCs in the US
60TWh/year wasted
( ~ 6 billion dollars)
11
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)
12
Packets/second
Traffic volume (incoming packets/second)
Idle
Active
Office
Home
Environment
Incoming traffic high even when idle
13
Fraction of idle time users can sleep
Sleep time when waking for every packet
Home
Office
Transition time
ts = 10s
Sorted Users
Waking for every packet is not enough
14
What kind of solution do we need?
Transparent
(Default WAKE)
Simplest
Wake:
Non Transparent
(Default IGNORE)
for everything
IGNORE or
WAKE
IGNORE,
WAKE or
RESPOND
?
Complex
Processing
15
Outline
•
•
•
•
Potential and Need for Proxying
Deconstructing Traffic
Proxy Design Space
Proxy Architecture & Prototype
16
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)
17
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:
ts = 10s
(
ts = 1min (
)
Sleep 90% of the time
Sleep 40% of the time
)
• If we sleep well even for large ts:
• If we sleep little even for small ts:
P is sleep friendly
P is sleep unfriendly
18
Computing half_sleep
• Compute sleep for discrete transition times
– 1s … 15min
ts_50 = largest transition time ts
for which sleep > 50%
1min < ts_50 < 2min
– e.g. ts_50 = 5s means protocol P wakes
the machine up every 10s
19
Transition
time
Sleep
(% time)
1s
99%
2s
98%
5s
95%
10s
90%
30s
70%
1min
55%
2min
30%
5min
15%
10min
11%
15min
8%
Traffic Composition
Unicast
Multicast
Broadcast
Home
Office
Home
INCOMING
•
Office
OUTGOING
Majority of incoming traffic is multicast or broadcast
- mostly useless network chatter
20
Deconstructing Broadcast
• Traffic volume
• Half_sleep
Can be handled
by simple responses
Can be ignored
21
Deconstructing Multicast
• Key offenders (half_sleep)
Can be ignored
Can be handled
by simple responses
22
Deconstructing Unicast
• Key offenders (half_sleep)
TCP
UDP
23
10-20s
1-2min
UDP
TCP
1-2min
8-15min
Outline
•
•
•
•
Potential and Need for Proxying
Deconstructing Traffic
Proxy Design Space
Proxy Architecture & Prototype
24
What kind of solution do we need?
Transparent
(Default WAKE)
Nothing
IGNORE or
WAKE
IGNORE,
WAKE or
RESPOND
Wake:
Non Transparent
(Default IGNORE)
for everything
Ignore: HSRP, EIGRP,PIM,
IPX, LLC, EIGRP,
ARP (for others)
Wake:
everything else
Respond: ARP, NBNS, SSDP,
IGMP, ICMP
Ignore:
same
Wake:
for everything else
More
Complex
Processing
25
Wake:
telnet, ssh, VNC, SMB,
NetBios (for me)
Respond: ARP, NBNS, SSDP,
IGMP, ICMP
for everything else
Ignore:
Evaluation of Sample Proxies
Wake for
everything
Non-transparent proxies
(even simple ones)
are very efficient
Ignore or Wake.
Transparent
Office
Ignore, Wake or
Respond.
Transparent
Transparent proxies
could be good for
home, not office
Ignore, Wake or
Respond.
Non-transparent
Home
26
Outline
•
•
•
•
Potential and Need for Proxying
Deconstructing Traffic
Proxy Design Space
Proxy Architecture & Prototype
27
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.
28
Example proxy implementation
Happy
Sleepy
Grumpy
Proxy
29
Dopey
•
Standalone machine
on the same LAN
•
Implemented in Click
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
30
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
31
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.
32
Thank you!!!
33
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
34
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
35
% Idle Time
70
Home
50
98% of the cases, the following
packet arrival will be within 3 seconds
Office
40
30
20
10
0
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
20-40
40-60
> 60
% of idle time.
60
Second-long bins for inter-packet gaps
36