Tue, 06 May 2008
An interesting discussion appeared over on the NANOG mailing list, based on the article, Up to 300 Megawatt Worth of Keepalive Messages to be Saved by IPv6?
This points to an original study by Haverinin, Siren and Eronen at Nokia that shows how much energy is used via "keepalive" messages sent in VoIP, Instant Messaging and other systems, in order to satisfy NAT. In order to maintain connectivity through a NAT router these systems need to keep sending messages to stop the NAT router closing the connections. With IPv6 this would no longer be necessary. It turns out the power requirements are quite significant.
There is good work happening elsewhere in Linux and elsewhere in IT, to minimise the amount of energy wasted, such as the Less Watts project. But perhaps its worth doing an audit of the protocols we use, to see what energy savings we can use?
Posted by Hamish offatt at Wed May 7 02:30:35 2008
Its harder to answer than it first appears. IPv6 allows for better MTUs (eg. more use of Jumbo packets), but what will the packet sizes be in the future? Also power consumption is not linear with packet size, and packet size (and hence overhead) may vary. Most of the power was wasted in the devices tested by having to wake them up frequently, rather than continual processing (similarly, lots of the savings in the lesswatts.org project has been due to removing the ticks, and more flexibility in timer, even for the same work done).
One of the design goals of IPv6 is to allow easier processing in hardware. This is why the packet headers are larger. When working in 3Coms Silicon Design Group, I compared the power usage of a 3DES crypto design implemented in an ASIC with performing the same work on a Pentium M, to see what battery life we could save on a laptop. It was a factor fo 20 or so: 50mW vs. 1W for the main cpu. If the IPv6 handling was done in hardware, we could see similar savings.
(The savings were due to primarily to minimizing the amount of hardware that needed to be powered to do the processing. DES was originally designed to be done in hardware, and was easily localized to a small core. This may also be possible with IP routing and firewalling on small routers, for example, or initial packet inspection on mobile devices.)
Posted by Alastair McKinstry at Wed May 7 08:58:03 2008