“Skilled in the Art of Being Idle”

Skilled in the Art of Being Idle” looks at how to reduce energy consumption by network end hosts (primarily desktops and laptops). Modern computers have various “sleep” states that allow reduced power consumption during idle periods. However, putting a computer to sleep has several costs:

  1. Transitioning into and out of a sleep state requires time (the paper cites a recent paper that found that typical machines take 3-8 seconds to enter “S3” sleep state, and 3-5 seconds to resume).
  2. Sleeping hosts cannot respond to network packets; hence, they can lose their network presence (e.g. DHCP lease can expire and be reassigned to another host). They also cannot run periodic tasks (e.g. backup or virus scanning).

A naive approach would put idle nodes to sleep, and then awaken them (via established “wake-on-LAN” support) when a packet is delivered to the node. This is insufficient: the authors demonstrate that in both home and office environments, the inter-arrival time of packets destined for idle computers is too small, so the cost of transitioning into and out of sleep state would negate any significant power savings. To avoid this problem, prior work has proposed using a proxy to handle network traffic intended for a sleeping node. The proxy can either ignore the traffic (if appropriate); handle the packet itself (e.g. by responding to an ARP query for the sleeping node’s IP), or it can awaken the sleeping node and forward the packet to it, if necessary. The effectiveness of proxying therefore depends on most traffic for an idle node fitting into the first two categories.

The paper is an empirical study of 250 machines owned by Intel employees, to assess the need for proxying in practice; the potential benefit of proxying; the network traffic that must be handled by a proxy; and so on.

Summary of Findings

  • Most machines are idle, most of the time — on average, machines were idle 90% of the time.
  • Home and office idle network traffic is markedly different, in both inter-arrival time of packets for idle machines (offices have more such traffic), and the nature of this traffic.
  • A power-saving proxy would need to handle broadcast, multicast, and unicast traffic to achieve significant gains. However, broadcast and multicast traffic represents “low-hanging fruit”: a proxy that handles only broadcast and multicast traffic would recover 80% of the idle time in home environments, and over 50% of the idle time in office environments.
  • For broadcast, address resolution (ARP, NBNS) and service discovery (SSDP for UPnP devices) protocols are the dominant sources of traffic for idle nodes. Both kinds of traffic are easy to proxy.
  • For multicast environments, routing traffic (HSRP, PIM) is the dominant source of traffic for idle nodes in an office environment. In a home environment, service discovery (SSDP) is dominant.
  • Their results for unicast traffic are less clear. They argue that only outgoing TCP connections dominate unicast traffic for idle nodes, and that less than 25% of this traffic is the result of some action a node initiated before becoming idle (and hence might need to be maintained in the idle state). They argue that outgoing traffic initiated while the machine is idle can often be batched together, or avoided entirely.
  • Advertisements

2 Comments

Filed under Paper Summaries

2 responses to ““Skilled in the Art of Being Idle”

  1. Pingback: Reducing electricity usage « Wheatland Computing

  2. Sumit Arora

    (I am looking the reply of this ?)
    Over OPENVPN – Forwarding of UPnP SSDP Multicast Packets from One Network to Another

    Network Configuration :

    (PC-A-Network-A – 192.168.60.X) –Switch(Router) — Internet (ISP) — Switch (Router) — (PC-B-Network-B – 192.168.10.X)

    What is happening ?

    libupnp device is running at PC-A-Network-A(192.168.60.128) and sending multicast packets(SSDP-Notify) at 239.255.255.250:1900

    libupnp ctrlpoint is running at PC-B Network-B(192.168.10.104) and sending multicast packets(SSDP-Msearch) at 239.255.255.250:1900

    OpenVPN Server is running at PC-B Network-B

    OpenVPN Client is running at PC-A Network-A

    (open VPN fully configured, as both network can ping each other)

    Via using smcroute ( from this : http://bda.ath.cx/blog/2009/01/24/multicast-routing-upnp-traffic-with-linux/), its possible
    to route PC-A-Network Packets to Network-B (SSDP-Multicast Packets), and vice versa.

    What is not hapening ?

    PC-A sending multicast SSDP Packets , and those are forwarded via openVPN to Network -B and vice versa, but no one accepts the multicast packets received from another network ?

    Is there any body can explain ?

    Do I need to configure iptables rules so that packet should be forwarded ? Or required to add some NAT rules or Is it possible to do this scenario

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s