Transcript presentation name

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
2
ICSI & Intel Research
Intel Research
UC Berkeley
LBNL
Intel Research
Intel Research
Motivation
Systems draw significant power when idle
Power draw
Go to sleep:
+ saves power (< 5W in S3)
-
||
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
Our contributions
•
We 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
Parallel Efforts
– Somniloquy
– Intel Remote Wake Technology© (RWT)
– Our work (complementary): trace-driven evaluation of the
broader benefits and design tradeoffs
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)
100%
75%
off
asleep
50%
active
idle
25%
0%
1
3
5
7
9
11
13
15
17
19
21
23
sorted users
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
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
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
Packets/second
Traffic volume (incoming packets/second)
Idle
Active
Office
Home
Environment
Incoming traffic high even when idle
14
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
15
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
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 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
19
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
20
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 traffic is multicast or broadcast
–
Mostly useless network chatter
21
Deconstructing Broadcast
• Traffic volume
• Half_sleep
Can be handled
by simple responses
Can be ignored
22
Deconstructing Multicast
• Key offenders (half_sleep)
Can be ignored
Can be handled
by simple responses
23
Deconstructing Unicast
• Key offenders (half_sleep)
TCP
UDP
24
10-20s
1-2min
UDP
TCP
1-2min
8-15min
Outline
•
•
•
•
Potential and Need for Proxying
Deconstructing Traffic
Proxy Design Space
Proxy Architecture & Prototype
25
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
26
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
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
Happy
Sleepy
Grumpy
Proxy
30
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
31
INPUT
From Network Card
Unicast
to Host
Bcast
Unicast
from Host
Mcast
State
Querier
Learning
Module
Address Classifier
Other
Drop
State &
Info
Keeper
Drop
State
Broadcast Triggers
Bcast Classifier
ARP Solver
1: ARP Query
NBNS Solver
2: NBNane Query
...
Unicast
Triggers
Host State
Classifier
Default:
ASLEEP
Host State
Classifier
Other
ASLEEP
Other
Host State
Classifier
ASLEEP
Other
Drop
Drop
Actions
Drop
Drop
Automatic Response
Wake Up & Relay
Ucast Classifier
Response Generator
Magic Maker
Original
Packets
1: TCP Syn
2: ...
Ma
...
gic
Response
Template DB
Pa
c
Default:
ke
ts
ARP Solver
Drop
ARP Solver
Delayed
Per
Host Queues
Notifications
from StateKeeper
Queue
To Network Card
32
OUTPUT
Future Work & Conclusions
• Conclusions
– Waste in networked systems is a real problem (6 billion/year)
– We need proxying to solve it
– Low hanging fruit
• Simple actions go a long way
– Multiple design options, may depend on usage environments
• Future work:
– Use traffic analysis tools & proxy prototype to
• Inform ECMA standard specification
• Evaluate various proxy configurations
– Clean-slate energy-friendly protocol design
33
Thank you!!!
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
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
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
37
Distribution of inter-packet gaps
• Idea: split idle time into bins, based on inter-packet gaps (IPG):
1min
idle time
30% of time
1min < IPG < 2min
30% of time
IPG < 1min
38
40% of time
IPG > 2min