Transcript Enabling an Energy-Efficient Future Internet Through

Enabling an EnergyEfficient Future Internet
Through Selectively
Connected End Systems
Jim Spadaro and Ted Brockly
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
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

Motivation (cont.)



Underlying reason: our networking principles
Our architecture assumes connected hosts
Disconnectedness is dealt with as a problem
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

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

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

Proposed Architecture (cont.)

Selective Connectivity is between the traditional
Internet and DTN
Takes full advantage of reliable connectivity for
high-priority tasks
 Don’t assume that lack of connectivity implies
failure

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
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
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
Exposing State

Tussle between efficiency and security
Allows more efficient and reliable operation
 Also could result in too much information being
released

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”

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

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
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

Final Thoughts



Our thinking of the issues is in early stages
We likely don’t have all models
While energy savings has been the focus, the
resulting components could be useful in other
contexts

E.g., mobile hosts