PRESENTATION NAME

1
Skilled in the Art of Being IdleReducing Energy
Waste in Networked Systems
2
Skilled in the Art of Being IdleReducing Energy
Waste in Networked Systems
ICSI Intel Research Intel Research UC
Berkeley LBNL Intel Research Intel Research

• Sergiu Nedevschi
• Jaideep Chandrashekar
• Junda Liu
• Bruce Nordman
• Sylvia Ratnasamy
• Nina Taft

Presented by Manikandan Somasundaram
3
Motivation
Systems draw significant power when idle
Power draw
Remain powered on maintains connectivity -
wastes power (gt 50W )

• Go to sleep
• saves power (lt 5W)
• - systems lose network presence
• remote access
• scheduled tasks
• background tasks

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
• Is the problem worth solving?
• Potential energy savings
• What is the design space?
• Tradeoffs between design complexity savings
• 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

• Desktops (lt 10 of machines)

On averages, desktops are idle gt 50 of time
10
energy spent in different states

• Assume desktops and typical power draws
• 2W powered down, 3W asleep, 80W idle, 90W active

Desktops waste gt 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
14
Sleep time when waking for every packet

• Transition time
• ts 10s

Waking for every packet is not enough
15
What kind of solution do we need?
Transparent (Default WAKE)
Non Transparent (Default IGNORE)
Simplest
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 Ps 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

19
Computing half_sleep
Transition 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 gt 50

• 1min lt ts_50 lt 2min

20
Traffic Composition

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

21
Deconstructing Broadcast

• Traffic volume
• Half_sleep

22
Deconstructing Multicast

• Key offenders (half_sleep)

23
Deconstructing Unicast

• Key offenders (half_sleep)

UDP 1-2min
TCP 10-20s
TCP 8-15min
UDP 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?
Transparent (Default WAKE)
Non Transparent (Default IGNORE)
Nothing
IGNORE or WAKE
IGNORE, WAKE or RESPOND
More Complex Processing
26
Evaluation of Sample Proxies
Wake for everything
Ignore or Wake. Transparent
Office
Ignore, Wake or Respond. Transparent
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

• Standalone machine
• on the same LAN
• Implemented in Click

Proxy
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 dont 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 proxy
• dont wake protocols (e.g. IGMP, PIM, ARP)
• dont ignore protocols (e.g DHCP lease, NBNS
  queries for me, ARP queries for me)
• policy-dependent
• Method of proxying
• ignorable (drop) (e.g. router traffic)
• mechanical responses (e.g ARP, NBNS, SSDP, IGMP,
  echo ICMP)
• 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)

36
Idle Time