From d9a3b8a08f1b3ea2270dcdb6662e34fb0183bda2 Mon Sep 17 00:00:00 2001 From: Christopher Meiklejohn Date: Thu, 20 Aug 2015 10:34:33 -0700 Subject: [PATCH] Fix incorrect Latex quotations. --- doc/src.high-level/high-level-chain-mgr.tex | 26 ++++++++++----------- 1 file changed, 13 insertions(+), 13 deletions(-) diff --git a/doc/src.high-level/high-level-chain-mgr.tex b/doc/src.high-level/high-level-chain-mgr.tex index 91209fe..4e03759 100644 --- a/doc/src.high-level/high-level-chain-mgr.tex +++ b/doc/src.high-level/high-level-chain-mgr.tex @@ -150,12 +150,12 @@ main focus of this document. Humming consensus's goal is to manage Chain Replication metadata safely. If participants have differing notions of time, e.g., running on extremely fast or extremely slow hardware, then humming consensus -may "churn" rapidly in different metadata states in such a way that +may ``churn'' rapidly in different metadata states in such a way that the chain's data is effectively unavailable. In practice, however, any series of network partition changes that case humming consensus to churn will cause other management techniques -(such as an external "oracle") similar problems. +(such as an external ``oracle'') similar problems. {\bf [Proof by handwaving assertion.]} (See also: Section~\ref{sub:time-model}) @@ -167,14 +167,14 @@ practice of chain replication metadata management options. \subsection{``Leveraging Sharding in the Design of Scalable Replication Protocols'' by Abu-Libdeh, van Renesse, and Vigfusson} \label{ssec:elastic-replication} -Multiple chains are arranged in a ring (called a "band" in the paper). +Multiple chains are arranged in a ring (called a ``band'' in the paper). The responsibility for managing the chain at position N is delegated to chain N-1. As long as at least one chain is running, that is sufficient to start/bootstrap the next chain, and so on until all chains are running. This technique is called ``Elastic Replication''. The paper then estimates mean-time-to-failure -(MTTF) and suggests a "band of bands" topology to handle very large +(MTTF) and suggests a ``band of bands'' topology to handle very large clusters while maintaining an MTTF that is as good or better than other management techniques. @@ -212,7 +212,7 @@ Paxos, Raft, et al.), why bother with a slightly different set of assumptions and a slightly different protocol? The answer lies in one of our explicit goals: to have an option of -running in an "eventually consistent" manner. We wish to be able to +running in an ``eventually consistent'' manner. We wish to be able to make progress, i.e., remain available in the CAP sense, even if we are partitioned down to a single isolated node. VR, Paxos, and Raft alone are not sufficient to coordinate service availability at such @@ -250,9 +250,9 @@ timestamps, physical or logical. Any mention of time inside of data structures are for human/historic/diagnostic purposes only. Having said that, some notion of physical time is suggested for -purposes of efficiency. It's recommended that there be some "sleep -time" between iterations of the algorithm: there is no need to "busy -wait" by executing the algorithm as quickly as possible. See also +purposes of efficiency. It's recommended that there be some ``sleep +time'' between iterations of the algorithm: there is no need to ``busy +wait'' by executing the algorithm as quickly as possible. See also Section~\ref{ssub:when-to-calc}. \subsection{Failure detector model} @@ -278,7 +278,7 @@ will always be explictly noted. \subsection{Use of the ``wedge state''} -A participant in Chain Replication will enter "wedge state", as +A participant in Chain Replication will enter ``wedge state'', as described by the Machi high level design \cite{machi-design} and by CORFU, when it receives information that a newer projection (i.e., run-time chain state reconfiguration) is @@ -295,13 +295,13 @@ operation mode. \subsection{Use of ``humming consensus''} -CS literature uses the word "consensus" in the context of the problem +CS literature uses the word ``consensus'' in the context of the problem description at \cite{wikipedia-consensus} . This traditional definition differs from what is described here as ``humming consensus''. -"Humming consensus" describes +``Humming consensus'' describes consensus that is derived only from data that is visible/known at the current time. The algorithm will calculate @@ -478,7 +478,7 @@ Figure~\ref{fig:projection}. To summarize the major components: According to the CORFU research papers, if a server node $S$ or client node $C$ believes that epoch $E$ is the latest epoch, then any information that $S$ or $C$ receives from any source that an epoch $E+\delta$ (where -$\delta > 0$) exists will push $S$ into the "wedge" state and $C$ into a mode +$\delta > 0$) exists will push $S$ into the ``wedge'' state and $C$ into a mode of searching for the projection definition for the newest epoch. In the humming consensus description in @@ -775,7 +775,7 @@ is used by the flowchart and throughout this section. \item[E] The epoch number of a projection. -\item[UPI] "Update Propagation Invariant". The UPI part of the projection +\item[UPI] ``Update Propagation Invariant''. The UPI part of the projection is the ordered list of chain members where the Update Propagation Invariant of the original Chain Replication paper \cite{chain-replication} is preserved.