Proxying—Frequently Asked Questions

The questions below cover some information presented in the papers and slide sets elsewhere on this site, as well as some information only included here.

• Why create proxying functionality for PCs?
• What can fail when a PC is asleep?
• What is a proxy?
• Where could / should a PC proxy be located?
• What "costs" are there to proxying?
• Has anyone created a PC proxy yet?

Why create proxying functionality for PCs?

Many PCs are left on continuously today to retain full network connectivity.  Others are powered down (to sleep or off) when not in active use, precluding their users from the benefits of continuous connectivity.  The former problem results in substantial extra energy use; most energy used by desktop PCs (which runs into the $billions/year) in the U.S. occurs when no one is present.

What can fail when a PC is asleep?

Ability of the switch/router to find the PC on the network; ability of the PC to maintain its IP address (through DHCP); ability for applications to ......

What is a proxy?

A proxy is an entity other than the main processor of a device that undertakes activities to maintain the device's "presence" on the network, and wake it up when (and only when) necessary.

Where could / should a PC proxy be located?

The ideal location of the proxy is with the PC's network interface (NIC) components.  Being built-in to the system minimizes configuration, and coordination with the operating system.  Locating the proxy in the immediately adjacent network switch (or router) is also plausible, and could be important as a transitional tool, to allow proxying on machines that lack the hardware ability on their own.  A final possibility is to locate the proxy somewhere else; this is much less desirable as discussed in a separate question in this FAQ.

What "costs" are there to proxying?

There are a number of one-time design costs to create the proxying definition, create hardware and firmware that implements it (as revisions to existing NIC designs), and modify the operating system to enable and exchange data with the proxy.  For each proxying PC, the proxying NIC could cost slightly more than a standard version, but NIC components are not expensive to begin with, and any additional cost would be one or more orders of magnitude smaller than typical savings. 

Has anyone created a PC proxy yet?

Yes.  See Somniloquy: Maintaining network connectivity while your computer sleeps, published in March, 2008.  It describes the implementation of a proxy on a USB device that maintains WiFi connectivity (though the same exact principles apply to Ethernet).  What about "packet floods" that arrive while a system is asleep?

PCs (and other devices) already reduce their link rate on going to sleep.  At present, this can only be raised by the PC after it wakes up.  Once Energy Efficient Ethernet (see the Adaptive Link Rate project - link at left) is introduced, the switch may ask for the link rate to be increased if a flood of traffic arrives.  One may question whether such a flood will happen due to normal traffic (a bad-actor application could do this) but it could happen.  A proxy might have the capability to process packets at full speed, but since this is not a normal occurrence, many may be designed to only be able to handle packets at a rate that is slow compared to peak link capacity (but fast compared to normal packet receipt during sleep).  A proxy facing a flood of packets could decide to wake up the sleeping device in case some of the packets in the flood were ones which merited wakeup.  This is an extreme condition and determining the best approach(es) should not detract the general discussion about how to implement proxying.  A default answer is to simply drop packets that arrive if the buffer fills with packets awaiting examination by the proxy.

What issues could arise during system wakeup?

When a device wakes up, there is often a delay from when the wake-up signal occurs (whether internally generated or from the network) and when the system is fully ready to receive and respond to network queries. For older PCs, this can be on the order of ten seconds or more, though on modern ones just a few seconds (Microsoft specifies that Windows PCs shall wake up in less than two seconds ).  This time is very long by network standards, though not long enough to be a fundamental barrier.

Network protocols generally have mechanisms to retry sending packets when they are not acknowledged because IP networks assume some degree of unreliability.  These usually use "exponential backoff" features in resending packets so that a two second time to become fully active means that a system will receive a resent packet between two and four seconds after the initial wakeup event.

An exception to the above is UDP packets.  Many types of UDP packets don't apply to products while asleep because they are used to transfer data for active processes (that is, if you were wanting to get those packets, you wouldn't be asleep).  UDP packets that trigger wakeup could be buffered by the proxy and passed up to the operating system once the system has woken up.  UDP packets are generally fairly small so do not require large amounts of memory to retain in a buffer.

How about a new "I'm waking up" packet?

It may be desirable to introduce a new type of packet that responds back to the sending IP device to the effect that "I am waking up and expect to be responsive in X seconds; please wait until then before sending more data".  The proxy could buffer some amount of additional packets during the wake-up period (the response packet could indicate this), but it is probably better if the sending device simply waits the indicated amount of time and then begins transmission with the original packet.  This potential mechanism deserves further examination for its difficulty in defining and implementing, and for its potential benefits.  It would only operate if both the sending device and proxy had the capability, but would not break networking if just one end had the feature.  It is possible that some contexts other than system wakeup could also make use of the feature; this should be explored. Note that only the sender and proxy would know about the feature.

What about third-party proxying?

Third-party proxying raises the most challenges in technical terms.  Some of the challenges are packet transfer, state transfer, and wakeup.  There are two basic approaches to implementing this: lower-layer and higher layer.  Each has advantages and disadvantages.   We first consider the lower-layer case.

Packet transfer is the fact that the proxy needs to see and examine all (?) packets destined for the sleeping system to understand what action if any is required.  It also means that the proxy needs to be able to generate packets which appear to the rest of the network as if they are emanating from the sleeping device.  By definition, the proxy is not in the immediately adjacent switch, so that some way to redirect those packets in that switch to the proxy.  This may be relatively straightforward if the proxy is attached to the same wired switch as the sleeping device, but gets much more difficult in other contexts.  As we expect network environments to get more complex (particularly in the home context), with various ways to bridge across diverse physical layers, the number of cases this could involve becomes very large, unless third-party ability is limited to devices in sufficiently close network proximity (which adds complication for the user and reduces system functionality).  On wakeup, the transfer of network identity back to the waking device also must occur, though may be simply the reverse of the original transfer.

State transfer is the fact that some amount of system state of the sleeping device must be transferred to the proxy when the system goes to sleep, and back up to the system from the proxy when it awakes (this discussed elsewhere).  Transferring the state raises issues for how to accomplish it and for timing re: the IP address transfer, introducing significant complexity.

Wakeup is assumed to be done by an existing mechanism, notably WOL or DPF for PCs.  If the proxy is on the same subne as the sleeping device, a standard WOL packet or properly constructed directed packet could accomplish this.  In a wireless context, this may be more difficult.  If the proxy is not on the same subnet, standard WOL won't work.

The advantage of this approach is that higher layer protocols are not involved.  The disadvantage is that many usage contexts may impose difficulties or impossibilities for implementing via this approach.

The case of higher-layer proxying relies on no changes to lower-layer protocols, but requires the introduction of new functions at some new or existing higher layer.  This means that any other device (that is, not the sleeping device or the proxy) for which the proxying will work must implement that higher-layer protocol.  It also may be (this as yet unclear) that applications on the other device must also implement that higher layer protocol.  Thus, "full" network presence is only for the subset of the network that implements the particular higher layer protocol, so is not "full" in a generic sense, unlike every other proxying mechanism addressed in this paper, and so really not the same concept.

For packet transfer, other devices know that the sleeping device is asleep and the identify of the proxy.  Thus, the other devices will either refrain from sending packets to the sleeping device, or send them directly to the proxy (the proxy may be able to offer some useful information about the product, including its capabilities and state).  In general, they will ask the proxy to wake up the sleeping device as the other device may not know how to wake it up or in fact be able to.

For state transfer, this occurs at the higher layer, so is fairly easy to implement, though some timing issues may require clever system design.

For wakeup, WOL won't work when the device is not on the same subnet, but DPF may work in all contexts.

The only major current effort to implement third-party proxying is within the Universal Plug and Play (UPnP) system.  Efforts to date to develop a fully functioning third-party proxying system within UPnP have not succeeded.  There is a proposed implementation of some pieces of this developed, but whether this will be expanded in future to a full system is not known.

In sum, each approach, lower-layer and higher-layer, has distinct advantages, but each also has significant (perhaps insurmountable) drawbacks in the ease of implementation, the range of cases for which full network presence can be achieved.   The challenges for third-party proxying seem significantly greater than the other two options, and so a less desirable choice.  In addition, the range of devices and protocols involve suggest that it would take far longer to implement such a system.  The elaborateness of the solution suggests that it would be far more brittle than the alternatives in how often it would work properly, greatly diminishing energy savings and user satisfaction.   Due to all this, it seems unwise to expend effort developing third-party proxying as a general solution to network connectivity.  It may be useful and helpful to develop it for niche product types, applications, or use contexts, but greatly limiting the scope of such implementations would also greatly decrease the difficulty in defining and implementing it.  As such, such a limited third-party proxy capability doesn’t particularly relate to the general network presence goal.

What about hacker port scans?

A common method for hackers to try to break into systems is to attempt opening a connection (via a TCP SYN request) on any plausible port that might be open.  When a system is awake, these are simply rejected by the operating system.  Today, sleeping systems simply ignore such requests.  A proxy should ignore all SYN requests to ports that the OS is not interested in to minimize wakeup, and for those to open ports, cause a wakeup.  For open ports, the proxy does note have the information to distinguish a legitimate request from an illegitimate one and so must rely on the OS for this, but by ignoring all the SYNs to open ports, the amount of wakeup this causes should be kept modest.  Systems behind corporate firewalls should be kept free of such scans in any case.

-->