[paper]: Two references went up

diff --git a/.gitignore b/.gitignore
index a253163..b07d97b 100644 (file)
--- a/.gitignore
+++ b/.gitignore
@@ -34,3 +34,4 @@ doc/arch/_region_.tex
 doc/arch/prv_aquarium.log
 doc/arch/aquarium.synctex.gz
 doc/arch/aquarium.ent
 doc/arch/prv_aquarium.log
 doc/arch/aquarium.synctex.gz
 doc/arch/aquarium.ent

+doc/arch/arch.texshop

diff --git a/doc/arch/aquarium.tex b/doc/arch/aquarium.tex
index 1aa67d3..2cc3c41 100755 (executable)
--- a/doc/arch/aquarium.tex
+++ b/doc/arch/aquarium.tex
@@ -61,7 +61,7 @@ customer billing. In this paper, we present the design and
 implementation of Aquarium, an extensible billing service software.
 Aquarium associates state changes in cloud resources with respective
 charges, based on configurable, user-specific and versioned charging
 implementation of Aquarium, an extensible billing service software.
 Aquarium associates state changes in cloud resources with respective
 charges, based on configurable, user-specific and versioned charging

-policy. The implementation of Aquarium is characterized by pervasive
+policies. The implementation of Aquarium is characterized by pervasive

 data immutability, actor message passing and service orientation.
 
 \section{Introduction}
 data immutability, actor message passing and service orientation.
 
 \section{Introduction}

@@ -147,13 +147,11 @@ restart.
 
 \section{Resources, Events, and Policies}
 
 
 \section{Resources, Events, and Policies}
 

-\paragraph{Events}Aquarium is the recipient of several types of events from external
+\paragraph{Events}
+Aquarium is the recipient of several types of events from external

 systems. More specifically, systems that manage the lifetime and
 operation of chargeable resources are responsible to send events that
 systems. More specifically, systems that manage the lifetime and
 operation of chargeable resources are responsible to send events that

-describe notable resource state changes. As an example, when a user
-consumes disk space during a file upload, a resource event for the
-\textsf{diskspace} resource along with the amount of bytes consumed
-will be sent to Aquarium.
+describe notable resource state changes. As an example, during a file upload a resource event for the respective \textsf{diskspace} resource along with the amount of bytes consumed will be sent to Aquarium.

 Figure~\ref{fig:resevt} presents a JSON-formatted
 \texttt{ResourceEvent}.
 
 Figure~\ref{fig:resevt} presents a JSON-formatted
 \texttt{ResourceEvent}.
 

@@ -163,16 +161,14 @@ stringstyle=\ttfamily,
 flexiblecolumns=true, aboveskip=-0.9em, belowskip=0em, lineskip=0em}
 
 \begin{lstlisting}
 flexiblecolumns=true, aboveskip=-0.9em, belowskip=0em, lineskip=0em}
 
 \begin{lstlisting}

-{
-  "id":"4b3288b57e5c1b08a67147c495e54a68655fdab8",
+{ "id":"4b3288b57e5c1b08a67147c495e54a68655fdab8",

   "occuredMillis":1314829876295,
   "receivedMillis":1314829876300,
   "userId": "31",
   "occuredMillis":1314829876295,
   "receivedMillis":1314829876300,
   "userId": "31",

-  "cliendId": "snf-vm-1",
-  "resource": "vmtime",
-  "value": 1,
-  "instance-id" : 3300,
-}
+  "cliendId": "pithos-storage-service",
+  "resource": "diskspace.1",
+  "value": 10,
+  "instance-id" : 3300 }

 \end{lstlisting}
 \caption{A JSON-formatted \texttt{ResourceEvent}} 
 \label{fig:resevt}
 \end{lstlisting}
 \caption{A JSON-formatted \texttt{ResourceEvent}} 
 \label{fig:resevt}

@@ -251,16 +247,13 @@ Aquarium {\sc dsl} to provide a scaling charge algorithm.
 
 \section{Computational aspects}
 
 
 \section{Computational aspects}
 

-%\subsection{Charging basics and cost policies}
-
-In order to charge based on the incoming resource events, time (\DTime) and the unit of measure (\DUnitR) for a resource ($R$) play a central role. \DUnitR can be taken into account either as whole value or as a difference \DeltaDUnitR. On first approximation, these lead to linear formulas that capture the essence of charging algorithms. Below, we will briefly  study charging scenarios for three well-known resources, namely \textsf{bandwidth}, \textsf{diskspace} and \textsf{vmtime}. For the analysis of each case, we assume: 
+In order to charge based on the incoming resource events, time (\DTime) and the unit of measure (\DUnitR) for a resource ($R$) play a central role. On first approximation, these lead to linear formulas that capture the essence of charging algorithms. Below, we will briefly  study charging scenarios for three well-known resources, namely \textsf{bandwidth}, \textsf{diskspace} and \textsf{vmtime}. For the analysis of each case, we assume: 

 \begin{itemize}
 \item The arrival of two consecutive resource events, happening at times $t_0$ and $t_1$ respectively, with a time difference of  $\Delta T = \Delta T_{0, 1} = t_1 - t_0$.
 
 \item The total values of resource $R$ for times $t_0$ and $t_1$ are $U_R^0$ and $U_R^1$ respectively.
 \begin{itemize}
 \item The arrival of two consecutive resource events, happening at times $t_0$ and $t_1$ respectively, with a time difference of  $\Delta T = \Delta T_{0, 1} = t_1 - t_0$.
 
 \item The total values of resource $R$ for times $t_0$ and $t_1$ are $U_R^0$ and $U_R^1$ respectively.

-%In general, for time $t_i$, the respective total value would be $U_R^i$.

 
 

-\item The charging unit is denoted as $C$. %By definition it is one credit.
+\item The charging unit is denoted as $C$.

 
 \item A factor in the form $[\frac{C}{D}]$ represents the resource-specific charging unit, where $C$ is defined above, and $D$ depends on the combination of the previously discussed dimensions ($T$, $U_R$) that enters the calculation. The meaning of the factor is probably clearer if we think of it as ``credits per $D$'', as the representation readily suggests.
 \end{itemize}
 
 \item A factor in the form $[\frac{C}{D}]$ represents the resource-specific charging unit, where $C$ is defined above, and $D$ depends on the combination of the previously discussed dimensions ($T$, $U_R$) that enters the calculation. The meaning of the factor is probably clearer if we think of it as ``credits per $D$'', as the representation readily suggests.
 \end{itemize}

@@ -280,15 +273,6 @@ Events for VM usage come into pairs that record \textsf{on} and \textsf{off} sta
 
 The charging algorithms for the sample resources given previously motivate related cost policies, namely \textsf{discrete}, \textsf{continuous} and \textsf{onoff}. Resources employing the \textsf{discrete} cost policy are charged just like \textsf{bandwidth}, those employing the \textsf{continuous} cost policy are charged like \textsf{diskspace} and finally resources with a \textsf{onoff} cost policy are charged like \textsf{vmtime}. Due to space limits we omit a more detailed analysis and the description of more involved scenarios.
 
 
 The charging algorithms for the sample resources given previously motivate related cost policies, namely \textsf{discrete}, \textsf{continuous} and \textsf{onoff}. Resources employing the \textsf{discrete} cost policy are charged just like \textsf{bandwidth}, those employing the \textsf{continuous} cost policy are charged like \textsf{diskspace} and finally resources with a \textsf{onoff} cost policy are charged like \textsf{vmtime}. Due to space limits we omit a more detailed analysis and the description of more involved scenarios.
 

-
-%\subsection{State management}
-
-%The only data mutation that takes place is the
-%actor's state. Since each actor handles only its user's events and
-%since there is only one actor for a user, the user state mutation is
-%guaranteed to be race-free and events for different users are handled
-%asynchronously and concurrently.
-

 Scheduled tasks compute total charges, the updated resource state and
 a total credit amount for each billing period. This computation is
 recorded to a persistent store, in an append-only fashion, for future
 Scheduled tasks compute total charges, the updated resource state and
 a total credit amount for each billing period. This computation is
 recorded to a persistent store, in an append-only fashion, for future

diff --git a/doc/arch/arch.tex b/doc/arch/arch.tex
index 0978be1..cb9e3e4 100755 (executable)
--- a/doc/arch/arch.tex
+++ b/doc/arch/arch.tex
@@ -1,19 +1,18 @@
-\paragraph{Architectural decisions} As in most similar systems, Aquarium's
+\paragraph{Architectural decisions} Aquarium's

 architectural design is driven by two requirements: scaling and fault
 architectural design is driven by two requirements: scaling and fault

-tolerance. Interestingly, Aquarium does not follow conventional design
-patterns; even though the first Aquarium prototype was developed along a 3
-tiered architecture, it quickly became clear that it would not meet our needs.
+tolerance. Although initially we used a 3-tiered architecture, it quickly became clear
+that it would not meet our needs.

 Complications arose from the fact that it was too difficult to describe
 versioned tree-based structures, such as the configuration {\sc dsl},
 in a relational format and to
 make sure that resource events were described in an abstract way that would
 include all future system expansions. Moreover, the single query that cloud
 services will be asking Aquarium continually (number of remaining credits) must
 Complications arose from the fact that it was too difficult to describe
 versioned tree-based structures, such as the configuration {\sc dsl},
 in a relational format and to
 make sure that resource events were described in an abstract way that would
 include all future system expansions. Moreover, the single query that cloud
 services will be asking Aquarium continually (number of remaining credits) must

-be answered within a few (less than 10) milliseconds for a large number of
-concurrent requests, which means that it must be somehow cached and
+be answered within a few milliseconds for a large number of
+concurrent requests, meaning that it must be somehow cached and

 automatically updated when new chargeable resources are invoked by the user.
 To address the requirements, Aquarium's data processing architecture was
 automatically updated when new chargeable resources are invoked by the user.
 To address the requirements, Aquarium's data processing architecture was

-based on the based on the event sourcing
+based on the event sourcing

 pattern~\cite{Fowle05}, while system state handling and processing components
 are modeled as collections of actors~\cite{Hewit73}.
 
 pattern~\cite{Fowle05}, while system state handling and processing components
 are modeled as collections of actors~\cite{Hewit73}.