Update
authorkristianf <kristianf@Kristian-Precis.sumptuous.sumptuouscapital.com>
Thu, 3 May 2012 17:13:51 +0000 (19:13 +0200)
committerkristianf <kristianf@Kristian-Precis.sumptuous.sumptuouscapital.com>
Thu, 3 May 2012 17:13:51 +0000 (19:13 +0200)
Document.tex

index 3413fbf..354d4d0 100644 (file)
@@ -30,7 +30,7 @@
 \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. DNS Service Records (\textbf{SRV}) are supported in GnuPG\cite{gnupg} since versions 1.4.10 and 2.0.13\cite{gnupg:srv}. This article will describe the implementation of SRV weights as currently found in the sub-pools \textit{eu.pool} and \textit{na.pool} as a basis for a discussion --- and implementation --- of a better suited algorithm for determining the SRV weights. \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. DNS Service Records (\textbf{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}. This article will describe the implementation of 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
 \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
@@ -59,7 +59,7 @@ The measurements in \ref{enum:new_proposal:responsetime} and \ref{enum:new_propo
 \begin{equation}\r
 R = \frac{R_1 + 0.9R_2 + 0.8R_3 + \cdots + 0.1R_{10}}{5.5}\r
 \end{equation}\r
-where $R_x$ define responsetime in current and earlier measurements and $R$ the basis of calculations. The further use of these measurements should not be strictly linear but penalize slower servers based on an exponential factor of some form, e.g. $(x - z)^y$ where $z$ is defined as a left-scew of the mean ($\mu$), as determined based on an $N(\sigma)$ rejection criteria, in order to remove outliers from the calculation, and $y$ is a static constant (even number) defined previous to implementation. As the calculation is dependant on data collected about all the servers, this should be implemented in \textsc{sks-status.php}\cite{pool:sks-status}. Only servers that are considered to be part of the main pool\footnote{Needs to be responsive, updated with appropriate number of keys and proper SKS version} will be considered. The bandwidth test could be retrieval of a know relatively long key, e.g. containing a JPEG userid that grows the size of the public key. \r
+where $R_x$ define responsetime in current and earlier measurements and $R$ constitute the basis for further calculations. The use of these measurements should not be strictly linear but penalize slower servers based on an exponential factor of some form, e.g. $(x - z)^y$ where $z$ is defined as a left-scew of the mean ($\mu$), as determined based on an $N(\sigma)$ rejection criteria, in order to remove outliers from the calculation, and $y$ is a static constant (even number) defined previous to implementation. As the calculation is dependant on data collected about all the servers, this should be implemented in \textsc{sks-status.php}\cite{pool:sks-status}. Only servers that are considered to be part of the main pool\footnote{Needs to be responsive, updated with appropriate number of keys and proper SKS version} will be considered. The bandwidth test could be retrieval of a know relatively long key, e.g. containing a JPEG userid that grows the size of the public key. \r
 \r
 The process could then be described as:\r
 \begin{enumerate}[label={\bfseries (\arabic*)},labelindent=20pt,labelwidth=20pt,leftmargin=!]\r
@@ -89,11 +89,11 @@ SRV weights would be defined as:
 \item $y$ is a constant (even number) that define penalization for deviation\r
 \end{itemize}\r
 \r
-As deviations from the mean is penalized in both directions, we left-scew $\mu$ by two $\sigma$ in order to give higher weights to more responsive servers. The SRV weights are then converted to an integer value, the servers are sorted by descending order of weights, and the top 10 servers are added to the pool. \r
+As deviations from is penalized in both directions, we left-scew $\mu$ by two $\sigma$ in order to give higher weights to more responsive servers. The SRV weights are then converted to an integer value, the servers are sorted by descending order of weights, and the top 10 servers are added to the pool. \r
 \r
 \subsection{Disadvantages}\r
 \begin{itemize}\r
-\item This methodology will not change the fact that measurements are being done from a single client (for each respective mirror of the site)\r
+\item This methodology will not change the fact that measurements are being conducted from a single client (for each respective mirror of the site)\r
 \item The complexity of the approach require more effort to implement. It will have to be determined that the difference to the output is significant for the overall performance compared to the current implementation --- or a simpler modification thereof. \r
 \end{itemize}\r
 \r