Microsoft's Sleep Proxy Lowers PC Energy Use

alphadogg writes "Microsoft researchers have slashed desktop energy use with a sleep proxy system that maintains a PC's network presence even when it is turned off or put into standby mode. Microsoft has deployed the sleep proxy system to more than 50 active users in the Building 99 research facility in Redmond, Wash., according to the Microsoft Research Web site and a paper that will be presented at the Usenix technical conference in Boston later this month. ... Sleep proxies allow machines to be turned off while keeping them connected to the network, waking the machines when a user or IT administrator attempts to access them remotely."

Comments

This is news?

[bushing]

This sounds awfully familiar... http://en.wikipedia.org/wiki/Sleep_Proxy_Service

Re:Wake on Lan?

[Stupendoussteve]

I guess they're claiming it's smart wake on lan. WoL requres sending a specific packet to the machine. Most people don't know to do this (an admin should, but otherwise...) and the network resources will be unavailable in the meantime. This system keeps the resources available and wakes the computer if they are actually needed. It does not rely on someone being smart enough to wake up the system themselves.

Macs have the option to Wake on Demand which requires the use of an Airport base station but seems to follow the same basic concept.

So they broke it, and made it theirs.

[Thruen]

My Macs have been able to do this for some time now, and not just in "small testbeds or simulations," so what's new? Oh, I know! Microsoft is going to take an existing technology, that works rather well in my experience, and they're going to turn it into a bloated software package that costs more than the hardware you run it on, but never actually works right without the use of additional third party hardware and software, and then it'll get praised by mindless Windows jockies claiming that Apple's version was "too simple" and only good for people who don't understand how to run Windows properly.
Wait... what?

Re:So they broke it, and made it theirs.

[Anonymous Coward]

Another syndrome identified:

replying without knowing the full story. Or even thinking about it.

Wake-on-lan is indeed nothing new, but Apple did it differently. They combined it with Multicast DNS (Bonjour) and placed it in the ROUTER. This means that it's the router that traps a request for your computer, and send a WOL first. There's no 'wakeup' button to press anywhere, it work automatically. Your PC might support WOL too, but are you using it ? How do you wake it up ?

And by the way, Apple also implemented if for wireless devices (WMM) where WOL doesn't work.

Unfortunately, since Apple is not making any routers that you can use in your companies network, it only work on a home network if you have an Apple Airport Express or Extreme. Or if you have a Mac on the same subnet that is using Internet Sharing. So it doesn't work in a company where the biggest savings might be done.

Re:So they broke it, and made it theirs.

[Alan Shutko]

Actually, in this case, Macs have been doing it since Snow Leopard was released, with Airport base stations. The base station will act as a proxy for any Bonjour-advertised service. If the Mac is asleep, the Airport will continue to advertise the bonjour offers. If another machine tries to connect to one of those services, the router will see it and will send the WOL packet to the mac.

So this does satisfy the basic need. It looks like the MS solution goes a bit further to making it work in an enterprise environment. With Apple's Wake On Demand, you need to be using Apple router, while with MS's you can use anything. It also looks like it could span routers, which Apple's can't do (with the exception of Back to My Mac with MobileMe). MS's paper does mention Apple's sleep proxy in its section on prior work, though it doesn't go into details on the differences.

Re:Wake on Lan?

[Cley Faye]

It probably is, but for instance I can't use WOL because it requires a packet that can't propagate through a router.

There is the possibility of having a smart router that allow WOL packets; some of them have a "act as a WOL proxy" option built-in, for examples.

Re:Wake on Lan?

[LordKronos]

For my home network, I've got it setup so that my web server (which I can access remotely) has a php web page which I can use to send a wake-on-lan signal to my desktop PC. It also opens up the remote desktop port on my router to my current IP.

Re:Making zombies even more zombie like!

[Anonymous Coward]

Hm. And as the post just above you points out, Macs have it too.
http://en.wikipedia.org/wiki/Sleep_Proxy_Service

Now all my machines are Linux, save for one Windows, but I think Macs qualify as "on the news" and useful.

At least in this case.

But yes, useful is why I go w/ Linux.

Re:Wake on Lan?

[Anonymous Coward]

Wake on LAN is a local protocol because it has to be sent as a broadcast packet if the router doesn't know the MAC address of the target network card. If you can configure static ARP table entries, you can combine that with port forwarding and use unicast WoL even over the internet. Besides, many home routers have WoL functionality. The problem with plain WoL is that it isn't built into the protocols, it doesn't maintain the presence of the server on the network and it doesn't keep the connection state on the server.

Re:Wake on Lan?

[Rockoon]

So, basically it's a wake on lan, but that which works everytime some moron is doing a portscan or ssh-breakin attempt on your system? Why would such a system even have a off mode?

..so basically, no its not like wake on demand.

"SleepNotifier alerts SleepServer just before the client goes to sleep, and SleepServer ensures that all incoming traffic meant for the client comes to the proxy instead," Microsoft writes in another article titled "Trying to cure PC insomnia." "The proxy server's role is to monitor traffic and respond accordingly. For some requests, it responds on behalf of the client so the client can continue sleeping, and others it ignores. Some traffic, such as a user access request, causes the SleepServer proxy to awaken the client and present the user with apparently seamless remote access."

So basically we have a system that uses Wake On Lan to wake the remote machine automatically for user requests, but also avoids waking it for stupid shit like pings.

This is, in effect, what other researchers are trying to solve in a decent manner. Wake On Lan requires the waker to know a thing or two about the sleeping system (for example, that its sleeping) and simple frontend devices that have solved this in the past wake the system for everything and are also permanent proxies (proxying even when the system ISNT sleeping, for example)

Re:MS invented here JUST LIKE THEY ALWAYS DO

[0100010001010011]

It's also OpenSource: Note: see mDNSResponder source code at www.macosforge.org, which includes a full implementation of the DNS-SD/mDNS Sleep Proxy Service, available under the Apache 2.0 Open Source license. AND written up as a specification http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns-11

Meaning if Linux or *BSD wanted to they too could also have it too. In fact, I'm really hoping that they do because I'd love to not have to send a WOL to my HTPC or Server when I want it to download something. I can just have my sheevaplug wget an address and have it wake itself.

Re:Wake on Lan?

[Anonymous Coward]

... it'd be silly to set up a 2nd machine running 24/7 so that I could turn mine off a few hours a day.

FTFPDF:

3.3.3 Network-Based Sleep Proxies
This approach was proposed in [15], its feasibility re-
cently given careful study by [29].
How it works: This approach relies on a separate ma-
chine acting as a sleep proxy for the sleeping machine.
The sleep proxy detects when a client goes to sleep. It
then modies Ethernet routing (Sec. 4.3.1) to ensure that
all packets destined for the sleeping machine are deliv-
ered to the sleep proxy instead. The proxy examines the
packets, and wakes up the sleeping client when needed,
by sending a Wake-On-LAN (WOL) [43] packet.
Pros: Very little hardware support is required from the
client machine - the client NIC only needs to support
WOL. As the sleep proxy runs on a separate, general
purpose computer, it has great exibility in handling in-
coming trafc for the sleeping machine. The sleep proxy
can do complex, conditional packet parsing and can even
wake the sleeping machine based on non-network events
such as requests by system administrators, users entering
the building (with support from building access systems),
etc. This design also scales well (Sec. 7.5.2).
Cons: This design requires deployment of a sleep proxy
on a separate machine (generally one per subnet sup-
ported). In most variations a client-side application must
be installed as well.
We have chosen this approach as it is both very easy to
deploy and requires minimal changes to user machines.

You just described Microsoft's plan. If only you had developed your idea fully, you could have patented the process first, and Microsoft would be your b****!

Re:Wake on Lan?

[Anonymous Coward]

Looks like Microsoft yet again attempts to take credit for "inventing" something that we've all been using for years.

If the Apple people here could calm down a bit and actually read the paper (at least RTFA), they would see that...

a) Actually MS is claiming no such thing, quite the opposite, they are actively acknowledging that others are working on sleep proxy research, and explaining what they have done different. This is published research, not marketing or fanboyism.

b) This is not just Wake on Lan. It's a smart automation of sleep/wake-on-lan functionality designed for enterprise network use. Waking hosts automatically (not by manual WOL command) if needed, but not unecessary. In a complex enterprise network environment with constant traffic complexity.

A short quote from the article:

"The proxy server's role is to monitor traffic and respond accordingly. For some requests, it responds on behalf of the client so the client can continue sleeping, and others it ignores. Some traffic, such as a user access request, causes the SleepServer proxy to awaken the client and present the user with apparently seamless remote access."

Re:MS invented here JUST LIKE THEY ALWAYS DO

[kjart]

It's a good thing you're here to call out bullshit on Slashdot! I mean, Microsoft contending it invented all this in such a _cowardly_ way...oh wait, FTFA:

Microsoft's research group isn’t the first to work on a sleep proxy – or even the only one presenting sleep proxy research at Usenix – but Microsoft contends that most previous work has evaluated sleep proxies only in small testbeds or simulations.

Phew, so Microsoft Research is presenting a research paper on this subject. Crisis averted.

Re:Wake on Lan?

[rinoid]

This is the way it works on OSX ... The machine appears available as a network resource yet remains asleep until yo attempt to utilize one of its hosted network services, afterwhich it wakes up. Does not wake for ping.

Linux or *BSD

[200_success]

It's also OpenSource [...] Meaning if Linux or *BSD wanted to they too could also have it too.

They could, if it weren't patented.

Re:Linux or *BSD

[0100010001010011]

It's an Apache 2.0 license probably just for that reason:
http://www.opscode.com/blog/2009/08/11/why-we-chose-the-apache-license/

While the 3-Clause BSD license allows you to do pretty much anything you want with the code in question, it provides no direct language around these areas. The Apache License, on the other hand, does. It makes very clear that individual contributors grant copyright license to anyone who receives the code, that their contribution is free from patent encumbrances (and if it is not, that they license that patent to anyone who receives the code,) and that use of Trademarks extends only as far as is necessary to use the product. It also includes a patent termination clause, should a lawsuit arise.

So, if you use Apple's mDNS code, you're in the clear. If you try and reinvent something, (like microsoft is doing) are in violation in Apple's patents you're in trouble.