Remove Jeff as author for now
authorkristianf <kristianf@Kristian-Precis.sumptuous.sumptuouscapital.com>
Sat, 5 May 2012 22:30:08 +0000 (00:30 +0200)
committerkristianf <kristianf@Kristian-Precis.sumptuous.sumptuouscapital.com>
Sat, 5 May 2012 22:30:08 +0000 (00:30 +0200)
Document.tex

index 51b0575..6cfc43d 100644 (file)
@@ -16,7 +16,7 @@
 \hypersetup{hyperindex=true,hyperfootnotes=true,linktocpage=true,colorlinks=true,linkcolor=blue,urlcolor=red,citecolor=magenta}\r
 \r
 \title{Improving DNS Service Record (SRV) weights in sks-keyservers.net}\r
-\author{Kristian Fiskerstrand \and Jeffrey Johnson}\r
+\author{Kristian Fiskerstrand}\r
 \r
 \pagestyle{fancyplain}\r
 \fancyhead{}\r
@@ -30,7 +30,9 @@
 \r
 \r
 \section{Introduction}\r
-\url{http://sks-keyservers.net} provide a convenient way for end users of the security framework OpenPGP\cite{openpgp} to access synchronised and responsive HKP\cite{hkp} keyservers, mainly based on the software SKS\cite{sks}. A pool of keyservers is available at hkp://pool.sks-keyservers.net in addition to various sub-pools. This article will describe the implementation of DNS Service Records (\textbf{SRV}) weights as currently found in the sub-pools \textit{eu.pool} and \textit{na.pool} as a basis for a discussion and propose a better suited algorithm and implementation for determining the SRV weights. SRV provide a mechanism for directing more of the traffic to specific servers and is supported in GnuPG\cite{gnupg} since versions 1.4.10 and 2.0.13\cite{gnupg:srv}, whereby it is currently not supported by PGP\cite{pgp,pgp:srv}. Clients not supporting the SRV weights directly will, however, still benefit as these are used as selection criteria for which of the servers are included with regular A and AAAA DNS records in the sub-pools. \r
+\url{http://sks-keyservers.net} provide a convenient way for end users of the security framework OpenPGP\cite{openpgp} to access synchronised and responsive HKP\cite{hkp} keyservers, mainly based on the software SKS\cite{sks}. A pool of keyservers is available at hkp://pool.sks-keyservers.net in addition to various sub-pools. This article will describe the implementation of DNS Service Records (\textbf{SRV}) weights as currently found in the sub-pools \textit{eu.pool} and \textit{na.pool} as a basis for a discussion and propose a better suited algorithm and implementation for determining the SRV weights. \r
+\r
+SRV provide a mechanism for directing more of the traffic to specific servers and is supported in GnuPG\cite{gnupg} since versions 1.4.10 and 2.0.13\cite{gnupg:srv}, whereby it is currently not supported by PGP\cite{pgp,pgp:srv}. Clients not supporting SRV weights directly will, however, still benefit as these are used as selection criteria for which of the servers are included with regular A and AAAA DNS records in the sub-pools. \r
 \r
 \section{Current implementation}\r
 Currently the SRV weights are based on a simple network timing, where that status page\cite{sks:statuspage} of a given SKS keyserver is being downloaded, and the full calculation is being performed in \textsc{sks\_get\_peer\_data.php} \cite{pool:getpeerdata}. The SRV weight is calculated as:\r
@@ -39,7 +41,7 @@ Currently the SRV weights are based on a simple network timing, where that statu
 \text{weight} = (\text{\textbf{int}})\left(\frac{100}{\text{responsetime}}\right) \r
 \end{equation}\r
 \r
-Responsetime is defined (calculated) in \cite[lines~102--115]{pool:getpeerdata} and a local adjustment is applied to any SKS server on the local network of the pool server\cite[lines~119--122]{pool:getpeerdata}. The SKS servers are then sorted in descending order by their weights, and the top 10 servers are included in the respective sub-pool. The SRV weights are calculated on each full update run of the pool, currently running every two hours\r
+Responsetime is defined (calculated) in \cite[lines~102--115]{pool:getpeerdata} and a local adjustment is applied to any SKS server on the local network of the pool server\cite[lines~119--122]{pool:getpeerdata}. The SKS servers are then sorted in descending order by their weights, and the top 10 servers are included in the respective sub-pool. The SRV weights are calculated on each full update run of the pool, currently running every hour\r
 \r
 \subsection{Advantages}\r
 The advantage of eq.~\eqref{currentmethod} is that the calculation is transparent and easily constrained within the server discovery process. The resulting output values perform reasonably well, and a SRV capable client is performing most of the work in determining which server to direct the traffic to. \r