I'd seriously be looking at making current -software- run more efficiently
before counting ipv6-related power savings.
Adrian
Notwithstanding that fact that keepalives are a huge issue for tiny battery powered devices. There's a false economy in assuming those packets wouldn't have to be sent with IPV6...
Marc Manthey wrote:
found an related article about the power consumtion saving in ip6.
no, you found an article about bad nat design in a market lacking the
ability to stanardize on a clean one.
if you look, you can also find statements by the same folk explaining
how ipv6 will help prevent car accidents involving falling rocks. yes,
i am serious.
note that i work very hard on ipv6 deployment. i just don't encourage
or support marketing insanity.
randy
Good luck with that.
Obviously there is a lot to be gained at that end, but that doesn't mean we should ignore power use in the network. One thing that could help here is to increase the average packet size. Whenever I've looked, this has always hovered around 500 bytes for internet traffic. If we can get jumboframes widely deployed, it should be doable to double that. Since most work in routers and switches is per-packet rather than per-bit, this has the potential to save a good amount of power.
Now obviously this only works in practice if routers and switches actually use less power when there are fewer packets, which is not a given. It helps even more if the maximum throughput isn't based on 64-byte packets. Why do people demand that, anyway? The only thing I can think of is DoS attacks. But that can be solved by only allowing end-users to send an average packet size of 500 (or 250, or whatever) bytes. So if you have a 10 Mbps connection you don't get to send 14000 64-byte packets per second, but a maximum of 2500 packets per second. So with 64-byte packets you only get to use 1.25 Mbps.
I'm guessing having a 4x10Gbps line card that "only" does 14 Mpps total rather than 14 Mpps per port would be a good deal cheaper. Obviously if you're a service provider with a customer that sends 10 Gbps worth of VoIP you can only use one of those 4 ports but somehow, I'm thinking few people use 10 Gbps worth of VoIP...
Iljitsch
PS. Am I the only one who is annoyed by the reduction in usable subject space by the superfluous [NANOG]?
Obviously there is a lot to be gained at that end, but that doesn't
mean we should ignore power use in the network. One thing that could
help here is to increase the average packet size. Whenever I've
looked, this has always hovered around 500 bytes for internet traffic.
If we can get jumboframes widely deployed,
You don't need jumboframes, you just need to have working Path MTU Discovery.
Or hand-nail your MSS to 1400 or something. But if you don't do either of
those, you basically need to assume that the minimum MTU is 512 or so.
???
Very few people out there use an MTU significantly below 1500 bytes. A 1500-byte MTU will give you an _average_ packet size of ~1000 on long-lived TCP flows because there is one tiny ACK for every two full size data segments. (In the other direction, but let's not make things too complicated right now.) The reason that the average is more like half that is that on short interactions the last packet is shorter, and of course there's stuff like gaming, VoIP, DNS that simply uses small packets.
Now obviously this only works in practice if routers and switches
actually use less power when there are fewer packets, which is not a
given. It helps even more if the maximum throughput isn't based on 64-
byte packets. Why do people demand that, anyway?
Max throughput, or max packets/sec? Max data throughput happens at the
*other* end, with 9K mobygrams...
Right, with 9k packets you only need to send around 13 kpps to fill up 1 Gbps, with 1500 bytes it's some 83 kpps. Helps in overhead, TCP performance and (potentially) power use.
But someone who is sending a 200 byte packet today isn't going to send something larger when her MTU is increased from 1500 to 9000 so the _average_ won't increase by a factor 6.
PS. Am I the only one who is annoyed by the reduction in usable
subject space by the superfluous [NANOG]?
Those of us who are *really* annoyed by stuff like that usually cook
up a procmail recipe to strip it out..
I got my procmail set up so it mostly does what I need right now, better not mess with it...
From: Iljitsch van Beijnum [mailto:iljitsch@muada.com]
think of is DoS attacks. But that can be solved by only allowing end-
users to send an average packet size of 500 (or 250, or whatever)
bytes. So if you have a 10 Mbps connection you don't get to
send 14000
64-byte packets per second, but a maximum of 2500 packets per
second.
So with 64-byte packets you only get to use 1.25 Mbps.
You have just cut out the VoIP industry, TCP setup, IM or most types of
real-time services on the Internet.
PS. Am I the only one who is annoyed by the reduction in usable
subject space by the superfluous [NANOG]?
Yes you are the only one. 
Of course not. Like I said, as an average end-user with 10 Mbps you get to send a maximum of 2500 packets per second. That's plenty to do VoIP, set up TCP sessions or do IM. You just don't get to send the full 10 Mbps at this size.
* iljitsch@muada.com (Iljitsch van Beijnum) [Mon 05 May 2008, 10:09 CEST]:
PS. Am I the only one who is annoyed by the reduction in usable subject space by the superfluous [NANOG]?
No, and I'm just as annoyed by the (non-McQ) footer with superfluous information attached to each mail.
Hmm, I see value in that.
But, good luck trying to convince customers to take a pps limitation in addition to a Mbps limitation, whether they ever exceed that pps or not. You /might/ convince them to take a pps limitation only - but if they want to do 30Mbit (ie 2500pps @ 1500b) then your product needs to support that.
Maybe you just start calling "10Mbps" "10Mbps, assuming a 500b average packet size."
Anyway, nice idea in theory - putting more real world limitations in to sold product limitations - but I don't see it working out with marketing people, etc. unless someone has been doing it for years already. It'd be good if the world were all engineers though, huh?
NPE-XXX, anyone?
Adrian