[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large
From: |
Matthew Palmer |
Subject: |
Re: [Sks-devel] IPv6 peering; keydumps annoyingly large |
Date: |
Thu, 2 Jun 2011 15:10:42 +1000 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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.
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, (continued)
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, John Clizbe, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, Scott Grayban, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, Jeff Johnson, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, John Clizbe, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, David Shaw, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, Robert J. Hansen, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, Xian Stannard, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, Daniel Kahn Gillmor, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, Scott Grayban, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, Robert J. Hansen, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large,
Matthew Palmer <=
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, David Shaw, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, Scott Grayban, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, David Shaw, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, Robert J. Hansen, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, Daniel Kahn Gillmor, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, Scott Grayban, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, C.J. Adams-Collier KF7BMP, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, Jeff Johnson, 2011/06/01
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, Kiss Gabor (Bitman), 2011/06/02
- Re: [Sks-devel] IPv6 peering; keydumps annoyingly large, David Benfell, 2011/06/02