Re: [Sks-devel] IPv6 peering; keydumps annoyingly large

[Matthew Palmer]

On Wed, Jun 01, 2011 at 02:33:14PM -0700, Scott Grayban wrote:
> The current key saving method is bulky and just so you guys can get a
> idea on growth last year the dump was 3GB - as of today the dump is over
> 4GB so that is at least a 1GB increase -- so if that is a sign of usage
> in 5 to 10 years of growth the DB will become unmanageable -- in fact 1
> step to get into the pool is not going to work that well --> import a
> current dump of the DB.

You have two point on a curve (the size of keydumps).  What shape is the
curve that you're extrapolating from that data?  Without knowing the shape
of the curve, it's impossible to tell what the usage in 5 to 10 years would
be.

According to http://www.mkomo.com/cost-per-gigabyte, "space per unit cost
has doubled roughly every 14 months" (from 1980 to 2010); so the cost of
disk space is reducing exponentially; any usage of diskspace on SKS
keyservers would also have to be increasing exponentially for it to be any
sort of a problem.  Is it?

On the transfer side (not nearly as important since you only transfer a
keydump once),
http://drpeering.net/white-papers/Internet-Transit-Pricing-Historical-And-Projected.php
suggests that transit costs (which we can use as a proxy for end-user
traffic costs, although it won't be perfect) suggests that you're looking at
*at* *least* a 25% year-on-year reduction in traffic costs.  Does your
undisclosed graph of keydump size over time show a 25% year-on-year
increase?  If not, it's *still* going to be cheaper in the future to
transfer a dump than it is today, despite increases in size.

Oh, and all of this is, as far as I'm aware, disregarding inflation, which
also works to reduce the effective cost of setting up and running a
keyserver.

- Matt

-- 
The New York Times: the paper that asks for more verification from its
readers than its writers.