\section{Computational aspects}
-\subsection{Charging basics}
-
-Charging, based on a resource event, is inherently multidimensional.
-Time (\DTime) is always one dimension to consider: there are resources
-whose charging is based on the passing of time. Also, rather
-obviously, the unit of measure (\DUnitR) for a resource ($R$) is yet
-another dimension to take into account. These dimensions usually enter
-the formulas of the charging algorithms, although it is not necessary
-that all of them do. But there is one more aspect to consider, which
-clearly adds up to the multidimensionality of the problem. More
-specifically, \DUnitR can be taken into account either as whole value
-or as a difference \DeltaDUnitR. An avid reader may be already
-wondering about time. Shouldn't it be treated in the same footing, at
-least for reasons of conceptual uniformity? Shouldn't we treat both
-\DTime and \DeltaDTime? In reality, we \textit{always} work with time
-differences. Usually, \DeltaDTime means the time difference between
-two resource events for the same resource instance. In such a setting,
-\DTime would mean the time difference from some well-known and
-predefined point in time. This is generally a possibility, for example
-by considering the beginning of a billing period as the beginning of
-time as far as a particular charging calculation is concerned. So all
-combinations of either full values or differences can be considered,
-as given in Table~\ref{tab:dt}.
-
-\begin{table}[htdp]
-\label{tab:dt}
-\begin{center}
-\begin{tabular}{|c|c|c|}
-\hline
-&Time & Resource unit of measure \\
-\hline
-Absolute value & \DTime & \DUnitR \\
-Difference & \DeltaDTime & \DeltaDUnitR \\
-\hline
-\end{tabular}
-\end{center}
-\label{default}
-\caption{Considering time and resource unit of measure as absolute values or differences
-}
-\end{table}%
+\subsection{Charging basics and cost policies}
-The above reasoning, together with some dimensional analysis, leads to first-order formulas for the charging algorithms\endnote{We also omit multiplicative and additive constants.}. These formulas capture the qualitative and quantitative essence of resource charging. 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. \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:
\begin{itemize}
-\item The arrival of two consecutive resource events, happening at times $t_0$ and $t_1$ respectively. The time difference is denoted as $\Delta T = \Delta T_{0, 1} = t_1 - t_0$. We should note that not both events are needed in all three cases for the computation of credit charging.
+\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$. %By definition it is one credit.
\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}
\paragraph{\textsf{bandwidth}}
-In this case, an event (let us assume the one at $t_1$) records a change of bandwidth, using the relevant unit of measure $U_R$. The credit usage computation is:
-\begin{equation}
-\label{eq:bandwidth}
-\Delta U_R \cdot [ \frac{C}{U_R} ]
-\end{equation}
+In this case, an event at $t_1$ records a change of bandwidth, using the relevant unit of measure $U_R$. The credit usage computation is $\Delta U_R \cdot [ \frac{C}{U_R} ]$.
A concrete example is $\Delta U_R = \MB{10}$ and in this case the bandwidth charging unit $[ \frac{C}{U_R} ]$ is ``$credits$ per {\sc MB}'', since $U_R$ is measured in {\sc MB}.
\paragraph{\textsf{diskspace}}
-The charging calculation for the disk space usage takes into account the disk space $U_R^0$ occupied at $t_0$ together with the time passed, $\Delta T$:
-\begin{equation}
-\label{eq:diskspace}
-U_R^{0} \cdot \Delta T \cdot [ \frac{C}{U_R \cdot T} ]
-\end{equation}
+We take into account the disk space $U_R^0$ occupied at $t_0$ together with the time passed, $\Delta T$. The credit usage computation is $U_R^{0} \cdot \Delta T \cdot [ \frac{C}{U_R \cdot T} ]$.
That is, when we receive a new state change for disk space, we actually calculate for how long we occupied the total disk space without counting the new state change. If we had \GB{1} at $t_0 = \secs{1}$ and we gained another \GB{3.14} at $t_1 = \secs{3.5}$ then we are charged for the \GB{1} we occupied for $3.5 - 1 = 2.5$ seconds. The disk space charging unit $[ \frac{C}{U_R \cdot T} ]$ is ``$credits$ per {\sc GB} per $sec$'', assuming $U_R$ (disk space) is measured in {\sc GB} and time in $sec$.
\paragraph{\textsf{vmtime}}
-Events for VM usage come into pairs that record \textsf{on} and \textsf{off} states of the VM. We use the time difference between these events for the credit usage computation:
-\begin{equation}
-\label{eq:vmtime}
-\Delta T \cdot [ \frac{C}{T} ]
-\end{equation}
-
-We should stress that each one of the above three formulas, (\ref{eq:bandwidth}), (\ref{eq:diskspace}) and (\ref{eq:vmtime}) is not to be taken as the exact computation machinery for the particular case. They are first-order approximations, indicative of what is involved and if it is involved as a total value (e.g. $U_R^0$) or a difference (e.g. $\Delta T$).
+Events for VM usage come into pairs that record \textsf{on} and \textsf{off} states of the VM. We use the time difference between these events for the credit usage computation, given by $\Delta T \cdot [ \frac{C}{T} ]$.
-\subsection{Cost policies}
-Using the above analysis, we can now easily define cost policies. Specifically, the three available cost policies affect the calculation
-of the amount of resource usage to be charged as follows:
+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.
-\begin{itemize}
- \item Resources employing the \textsf{discrete} cost policy are charged based on Formula~(\ref{eq:bandwidth}), just like \textsf{bandwidth}.
-
- \item Resources employing the \textsf{continuous} cost policy are charged based on Formula~(\ref{eq:diskspace}), just like \textsf{diskspace}.
-
- \item Resources using the \textsf{onoff} cost policy are charged based on Formula~(\ref{eq:vmtime}), just like \textsf{vmtime}.
-\end{itemize}
\subsection{State management}
-External systems communicate resource state changes and user state
-changes by means of respective events. Aquarium, upon reception of
-these events, records them to an append-only immutable log and then
-forwards them to the appropriate user's actor mailbox. All
-computations that are triggered by an event are handled by the
-respective user actor. 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.
+%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
projects / aquarium / commitdiff