Enabling an Energy-Efficient Future Internet Through Selectively Connected End Systems

1
Enabling an Energy-Efficient Future Internet
Through Selectively Connected End Systems

• Jim Spadaro and Ted Brockly

2
Motivation

• Studies have found
• 67 of office desktop computers fully powered
  after work hours
• Average residential computer is on 34 of the
  time
• Half the time no one is actively using the
  machine
• Potential energy savings estimated 0.8 - 2.7
  billion in the US per year

3
Motivation (cont.)

• Why are these machines fully powered?
• Sporadic, occasional access
• User remote access
• Administrative access (backups, patches, etc.)
• Service provider access (set-top boxes, VoIP
  systems, etc)
• Preservation of network state

4
Motivation (cont.)

• Underlying reason our networking principles
• Our architecture assumes connected hosts
• Disconnectedness is dealt with as a problem

5
Related Work

• More limited solutions to power management exist
• TCP keep-alive response proxies
• Dynamic Power Management and Energy Star
• Wireless power-level tiers
• Wake-on-LAN

6
Related Work (cont.)

• Traditional Internet
• Assumes constant connectivity
• Lack of connectivity signals failure
• Delay/Disruption Tolerant Networks
• Emphasize connectivity in low-reliability
  environments
• Store-and-forward architecture
• More suited to extreme environments

7
Proposed Architecture

• Selective Connectivity
• Allow 3 states
• On Full connectivity
• Off No connectivity
• Asleep Grey area between the two
• Allow a host to be asleep and still have presence
  on the network
• Limit powering up host to important tasks

8
Proposed Architecture (cont.)

• Selective Connectivity is between the traditional
  Internet and DTN
• Takes full advantage of reliable connectivity for
  high-priority tasks
• Dont assume that lack of connectivity implies
  failure

9
Chatter

• All incoming data is not necessarily important
• Computer not previously engaged on network
  received 6 pps over a 12-hour period
• Ignore or have low-power handling of unimportant
  data

10
Assistants

• Allow hosts to handle low power tasks while
  sleeping
• Keep-alive requests
• Renewing DHCP leases
• Responding to ARP queries
• Soft error tell remote hosts to retry
• High-power tasks wake host

11
Assistants (cont.)

• Location is unimportant
• Powered-on NIC
• Independent system
• Built into switches
• Introduces a new point of failure
• Degree dependent on amount of responsibility

12
Exposing State

• Tussle between efficiency and security
• Allows more efficient and reliable operation
• Also could result in too much information being
  released

13
Evolving Soft State

• Soft state is one of the architectural successes
  of the Internet
• Maintaining soft state across selectively
  connected hosts poses a problem
• Two possible approaches
• Proxyable State maintenance of the state by
  assistant
• Limbo State Recognition of distinction between
  inexplicably gone and asleep

14
Host-based Control

• How selectively connected hosts are seen by
  others should be a policy decision
• Examples
• What is exposed to which peers
• What tasks are delegated
• What events should wake the host

15
Application Primitives

• Could we design general application primitives to
  aid selective connectivity?
• E.g., a generalized keep-alive that goes beyond a
  binary answer
• E.g., a way to share a list of files the host
  makes available on a p2p network
• Perhaps there are not a set of primitives, but we
  would need to provide a program that encodes our
  needed functionality to an assistant

16
Security

• Security issues cut across our thinking
• Many questions
• How can tasks be securely delegated?
• How does a peer know an assistant has authority
  to act on behalf of a host or app?
• How do we layer our use of cryptography to expose
  information needed by an assistant without
  exposing sensitive data

17
Final Thoughts

• Our thinking of the issues is in early stages
• We likely dont have all models
• While energy savings has been the focus, the
  resulting components could be useful in other
  contexts
• E.g., mobile hosts