diff --git a/.vscode/settings.json b/.vscode/settings.json
index 314663037274c2f256cb030019e72d86ec25126c..95962b5df03d32972e811106c6fe7215a50b68c4 100644
--- a/.vscode/settings.json
+++ b/.vscode/settings.json
@@ -34,6 +34,7 @@
"bijective",
"binom",
"bmatrix",
+ "bottomrule",
"captionof",
"cheatsheets",
"chktex",
@@ -74,6 +75,8 @@
"midrule",
"mnode",
"multicols",
+ "multicolumn",
+ "multirow",
"multline",
"mydescription",
"myenumerate",
@@ -96,6 +99,7 @@
"psset",
"rearrangeable",
"recurse",
+ "scalability",
"scalebox",
"smallcaps",
"sqcases",
diff --git a/main.tex b/main.tex
index f631af9c74dd022808962ecbb877ed4c6cb47a34..2480b10845bcc67df544195b455b6920b8857531 100644
--- a/main.tex
+++ b/main.tex
@@ -54,5 +54,9 @@
\printbibliography%
\end{frame}
+
+ \appendix
+
+ \input{sections/appendix}
\end{document}
diff --git a/packages.tex b/packages.tex
index 30d2a6faa227e9c62c5ce63dee1243f1acfaab73..20eb8a89e6ef75529ab6331b71018f4927095b6c 100644
--- a/packages.tex
+++ b/packages.tex
@@ -12,6 +12,7 @@
\usepackage{xpatch}
\usepackage{hyperref}
\usepackage{hyperxmp}
+\usepackage{multirow}
\usepackage[
backend=biber,
diff --git a/sections/appendix.tex b/sections/appendix.tex
new file mode 100644
index 0000000000000000000000000000000000000000..003e3ccb91c1bef9a5b8932f7f85c5c309c69a16
--- /dev/null
+++ b/sections/appendix.tex
@@ -0,0 +1,60 @@
+% cSpell:ignore DBLP
+
+\begin{frame}{Max stash size grows linearly with $\lambda$}
+
+ \begin{center}
+
+ \includegraphics[
+ height=5cm,
+ keepaspectratio
+ ]{static/images/max-stash-size-linear.png}
+
+ \end{center}
+
+ Figure 3 from~\cite{DBLP:journals/corr/abs-1202-5150}.
+
+\end{frame}
+
+\begin{frame}{Max stash size does not depend on $N$}
+
+ \begin{center}
+
+ \includegraphics[
+ height=5cm,
+ keepaspectratio
+ ]{static/images/stash-size-does-not-depend-on-n.png}
+
+ \end{center}
+
+ Figure 4 from~\cite{DBLP:journals/corr/abs-1202-5150}.
+
+\end{frame}
+
+\begin{frame}{Max stash size for large security parameters}
+
+ \begin{center}
+
+ \begin{tabular}{ l c c c }
+
+ \toprule%
+
+ \multirow{3}{*}{\textbf{Security parameter} $\lambda$} & \multicolumn{3}{c}{\textbf{Bucket size} $Z$} \\
+ & 4 & 5 & 6 \\
+ & \multicolumn{3}{c}{\textbf{Max stash size}} \\
+
+ \midrule%
+
+ 80 & 89 & 63 & 53 \\
+ 128 & 147 & 105 & 89 \\
+ 256 & 303 & 218 & 186 \\
+
+ \bottomrule%
+
+ \end{tabular}
+
+ \end{center}
+
+ Figure 5 from~\cite{DBLP:journals/corr/abs-1202-5150}.
+
+\end{frame}
+
diff --git a/sections/conclusion.tex b/sections/conclusion.tex
index 5e874985bdd3f12dbca18f532da6f556be699173..3a2787a54672baa3b6e49b438e564df802f22241 100644
--- a/sections/conclusion.tex
+++ b/sections/conclusion.tex
@@ -1 +1,22 @@
+% cSpell:ignore DBLP
+
\section{Conclusion}
+
+ \begin{frame}{Conclusion}
+
+ \begin{quote}
+
+ Partly due to its simplicity, PathORAM is the most practical ORAM scheme known-to-date under a small amount of client storage.
+ We formally prove asymptotic bounds on PathORAM, and show that its performance is competitive with or asymptotically better than the best known construction (for a small amount of client storage), assuming reasonably large block sizes.
+ We also present simulation results that confirm our theoretic bounds.~\cite{DBLP:journals/corr/abs-1202-5150}
+
+ \end{quote}
+
+ \note{
+ The conclusion given in the paper is very concise, so I have just copied it down from the paper.
+ To iterate, pathORAM is simple, practical, requires small client storage.
+ The paper proves asymptotic bounds and negligible probability of failure.
+ Lastly, the practical evaluation of theoretical results is given.
+ }
+
+ \end{frame}
diff --git a/sections/evaluation.tex b/sections/evaluation.tex
index cd3fc7fa4ae187605271dd7840cc3987aebc8a35..abf257cdca30a72862c573c24976e855487cae2a 100644
--- a/sections/evaluation.tex
+++ b/sections/evaluation.tex
@@ -1 +1,104 @@
\section{Evaluation}
+
+ \begin{frame}{Stash Occupancy Distribution}
+
+ \begin{block}{Experiment setup}
+
+ \begin{itemize}
+ \item
+ PathORAM uses a binary tree with height $L = \ceil*{\log_2 N} - 1$.
+ % TODO: why?
+ \item
+ \emph{Stash occupancy} is the number of overflowing blocks.
+ Represents client's \emph{persistent} local storage.
+ \item
+ First load $N$ blocks into ORAM and then access each block in a round-robin pattern.
+ Worst-case access pattern in terms of stash occupancy.
+ \item
+ Single run for about 250 billion accesses after doing 1 billion accesses for warming-up.
+ \end{itemize}
+
+ \end{block}
+
+ \note{
+ In the experiments, authors used a binary tree of height $\ceil*{\log_2 N} - 1$.
+
+ Let us define \emph{stash occupancy} is the number of overflowing blocks.
+ Thus, this would be a client's persistent local storage in addition to $Z \log_2 N$ transient storage for storing single path.
+
+ We access PathORAM in a round-robin fashion --- it is proven to be the worst-case scenario for PathORAM\@.
+ Round-robin fashion is like $\{ 1, 2, \ldots, N, 1, 2, \ldots, N, \ldots, 1, 2, \ldots \}$.
+
+ Finally, they perform around billion accesses for warming-up, then 250 billion accesses for actual experiment.
+ }
+
+ \end{frame}
+
+ \begin{frame}{Stash Occupancy Distribution}
+
+ \begin{block}{Results}
+
+ \begin{itemize}
+ \item
+ Required stash size grows linearly with the security parameter.
+ Failure probability decreases exponentially with the stash size.
+ See appendix.
+ \item
+ Extrapolate those results for realistic values of $\lambda$.
+ See appendix.
+ \item
+ It is by definition infeasible to simulate for practically adopted security parameters (e.g., $\lambda = 128$)
+ \item
+ Required stash size for a low failure probability does not depend on $N$.
+ This shows PathORAM has good scalability.
+ See appendix.
+ \end{itemize}
+
+ \end{block}
+
+ \note{
+ Some of the key observations made after simulation.
+
+ Required stash size grows linearly with the security parameter, which is consistent with the theorem that failure probability decreases exponentially with the stash size.
+
+ This linearity was used to predict required stash size for realistic security parameters.
+ Note that it is by definition infeasible to simulate for practically adopted security parameters, since if we can simulate a failure in any reasonable amount of time with such values, they would not be considered secure.
+
+ Finally, it is discovered that required stash size does not depend on $N$, which proves that PathORAM is highly scalable.
+ }
+
+ \end{frame}
+
+ \begin{frame}{Bucket Load}
+
+ \begin{block}{Results}
+
+ \begin{itemize}
+ \item
+ For $Z \ge 5$, the usage of a subtree is close to the number of buckets in it.
+ Also holds for $Z = 4$.
+ % TODO why?
+ \item
+ For the levels close to the root, the bucket load is indeed 1 block.
+ \item
+ Leaves have slightly heavier loads as blocks accumulate at the leaves of the tree.
+ \item
+ $Z = 3$, however, exhibits a different distribution of bucket load and produces much larger stash sizes in practice.
+ \end{itemize}
+
+ \end{block}
+
+ \note{
+ Another set of observations about bucket load.
+
+ For $Z \in \{ 4, 5 \}$, the usage of a subtree is close to the number of buckets in it.
+
+ For the levels close to the root, the bucket load is 1 block.
+
+ Leaves have slightly heavier loads as blocks accumulate at the leaves of the tree.
+
+ $Z = 3$ is different.
+ It produces much larger stash sizes in practice, so should not be used in production.
+ }
+
+ \end{frame}
diff --git a/sections/overview-of-other-orams.tex b/sections/overview-of-other-orams.tex
index f32069edf38d9cec08fbb81689b3e92c352437df..3013338775aca967b57392efe7543c2778df77d4 100644
--- a/sections/overview-of-other-orams.tex
+++ b/sections/overview-of-other-orams.tex
@@ -15,7 +15,9 @@
Basic-HR & $N \log^2 N$ & $N \log^2 N$ & $N \log N$ & $1^b$ \\
BB-ORAM & $\log^2 N$ & $N \log^2 N$ & $N \log N$ & $1$ \\
TP-ORAM & $\sqrt{N}$ & $1$ & $N$ & $\sqrt{N} + \frac{N}{B}$ \\
- \textbf{Path-ORAM} & $\bm{\log N}$ & $\bm{1}$ & $\bm{N}$ &\footnote{$\BigO{\log N} \cdot \omega(1) + \BigO{\frac{N}{B}}$}
+ \textbf{Path-ORAM} & $\bm{\log N}$ & $\bm{1}$ & $\bm{N}$ &\footnote{$\BigO{\log N} \cdot \omega(1) + \BigO{\frac{N}{B}}$} \\
+
+ \bottomrule%
\end{tabular}
diff --git a/static/images/max-stash-size-linear.png b/static/images/max-stash-size-linear.png
new file mode 100755
index 0000000000000000000000000000000000000000..57b5074b984d09e677df1f8bf9d61bf38513e421
Binary files /dev/null and b/static/images/max-stash-size-linear.png differ
diff --git a/static/images/stash-size-does-not-depend-on-n.png b/static/images/stash-size-does-not-depend-on-n.png
new file mode 100755
index 0000000000000000000000000000000000000000..548bf2415d75930569d8cbfbc9829cbf31a4433d
Binary files /dev/null and b/static/images/stash-size-does-not-depend-on-n.png differ