Upload
joseph-short
View
218
Download
0
Tags:
Embed Size (px)
Citation preview
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)
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.
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