rejiggering sections as per caroline's request

Proposal/proposal.tex

@@ -44,7 +44,7 @@
 \newcommand{\PocketPattern}{\textsc{PocketPattern}\xspace}
 \hyphenation{Pocket-Pattern}
 
-\def\thetitle{CI-NEW: Enabling Pocket-Scale Data Management Research}
+\def\thetitle{CCRI: Medium: Collaborative Research: Enabling Pocket-Scale Data Management}
 \def\shorttitle{Pocket-Scale Data Management Research}
 \def\fromub{(\textbf{ub})}
 \def\fromosu{(\textbf{osu})}
@@ -96,6 +96,9 @@
   \subsection{Benchmarking Suite}
   \input{sections/description_benchmark.tex}
 
+  \subsection{Community Engagement}
+  \input{sections/community_engagement.tex}
+
 
   %\subsection{\PocketData Workshop and Outreach Efforts}
   %\input{sections/workshop.tex}
@@ -108,9 +111,6 @@
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-\section{Community Engagement}
-\input{sections/community_engagement.tex}
-
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
 \section{Collaboration Plan}

Proposal/sections/collaboration.tex

@@ -21,9 +21,9 @@ Task and project management will be done using the Issues and Project management
 
 \tinysection{Division of Responsibility}
 Although both sites will contribute to all aspects of the proposed infrastructure, we will ensure that responsibility for each component is clearly delineated.
-The University at Buffalo's project team will take responsibility for Components 1 (Measurement Platform) and 4 (Deployment Platform).
-Delaware State University's project team will take responsibility for Component 2 (Workload Synthesis).  
-Component 3 (Standalone Measurement Tool) will consist of components 1 and 2; Both teams will be responsible for documenting and packaging their components for external use.  The University at Buffalo's team will be responsible for distribution (website maintenance, preparing install scripts, etc\ldots).
+The University at Buffalo's project team will take responsibility for Components 1 (Testbed) and 2 (Measurement Software).
+Delaware State University's project team will take responsibility for Component 3 (Workload Synthesis).  
+Component 4 (Standalone Measurement Tool) will consist of components 2 and 3; Both teams will be responsible for documenting and packaging their components for external use.  The University at Buffalo's team will be responsible for distribution (website maintenance, preparing install scripts, etc\ldots).
 
 
 \tinysection{Regular video conferencing}  

Proposal/sections/community_engagement.tex

@@ -10,7 +10,7 @@ The result of this outreach is a collection of feedback and potential projects b
 A detailed description of these projects can be found above, in Section~\ref{sec:research}. 
 In summary, there is interest from researchers working on embedded databases, small-scale data management, personal sensing, query interfaces, and several closely related areas. 
 
-The planning proposal also supported the development and release of \PocketBench, a prototype implementation of Component 1, and \PocketPattern, a preliminary implementation of Component 2.  
+The planning proposal also supported the development and release of \PocketBench, a prototype implementation of Component 2, and \PocketPattern, a preliminary implementation of Component 3.  
 \PocketBench is available on GitHub~\cite{pocketdata:runner}, and documentation is available at the project website~\cite{pocketdata:website}. \PocketPattern is also available on GitHub~\cite{pocketdata:pattern}.
 Two papers on the technology involved in \PocketBench are presently under review at top database conferences, providing further advertisement opportunities.
 \PocketBench and the \PocketData website will serve as a focal point for the community's involvement by providing the community with a way to explore, discuss, and disseminate new data management use cases, and by offering a standard way to evaluate systems on those use cases.

Proposal/sections/description_benchmark.tex

@@ -1,6 +1,6 @@
 %!TEX root=../proposal.tex
 
-Understanding empirical results generated by components 1 and 2, and ensuring that these results are statistically significant and reproducible is hard.
+Understanding empirical results generated by components 2 and 3, and ensuring that these results are statistically significant and reproducible is hard.
 As things stand now, each research group typically has their own methodology and infrastructure for gathering measurements.
 Our goal is to provide a unified mechanism for gathering and analyzing performance and other characteristics for \PocketData.
 This will allow for an easier comparison of new mobile databases systems, optimizations, heuristics, and even measurements of platform change effects on mobile databases.   
@@ -9,6 +9,6 @@ Crucially this component will also make it easier for researchers to reproduce e
 
 
 \declarecomponent{A Plug-and-Play Benchmarking and Evaluation Suite}{
-We will package components 1 and 2 into a unified benchmarking suite with a statistical analysis engine.  
+We will package components 2 and 3 into a unified benchmarking suite with a statistical analysis engine.  
 The result will be a tool that ensures reproducibility of research results on mobile platforms.
 }

Proposal/sections/description_runner.tex

@@ -50,6 +50,31 @@ Recent Android phones since the Nexus 6 moved to the Interactive governor, which
 Both of these defaults, roughly, base their CPU frequency choice on how busy the CPU has been recently.
 
 
+\begin{figure*}
+\centering
+\begin{subfigure}{0.30\textwidth}
+\centering
+\includegraphics[width=\textwidth,trim={30mm 10mm 0 0}]{graphics/Stacked_C.pdf}
+\bfcaption{Saturated v. unsaturated}
+\label{fig:clean_dirty_C}
+\end{subfigure}
+\begin{subfigure}{0.34\textwidth}
+\centering
+\includegraphics[width=\textwidth]{graphics/YCSB_WorkloadC_TimingA-freq_timeline.pdf}
+\bfcaption{CPU frequency over time.}
+\label{fig:C_frequency_shifts}
+\end{subfigure}
+\begin{subfigure}{0.32\textwidth}
+\centering
+\includegraphics[width=\textwidth,trim={5mm 10mm 0 0}]{graphics/C_latencies.pdf}
+\bfcaption{Saturated v. unsaturated latency.}
+\label{fig:C_governor_latencies}
+\end{subfigure}
+\vspace*{-3mm}
+\bfcaption{YCSB Workload C}
+\trimfigurespacing
+\end{figure*}
+
 Android systems, however, elicit markedly different responses from these governors than do traditional DB systems.
 Server-class database workloads try to extract as much work as possible from the hardware.
 Hence, the heuristic read by the governor is that the CPU is completely, and continuously, busy.
@@ -85,31 +110,6 @@ Repeated idling, such as from lower loads or IO-blocked operations are interpret
 The frequency scaling operation is expensive:  No activity can be scheduled for several milliseconds while the core is scaled up or down.  
 Hence, when the CPU is running at a low frequency, a database with a burst of work takes a double performance hit: first from having an initially slower CPU and second from waiting while the core scales up\footnote{Ironically, this means that a database running on a non-saturated CPU could significantly improve latencies by simply busy-waiting to keep the CPU pinned at a high frequency.}.
 
-\begin{figure*}
-\centering
-\begin{subfigure}{0.30\textwidth}
-\centering
-\includegraphics[width=\textwidth,trim={30mm 10mm 0 0}]{graphics/Stacked_C.pdf}
-\bfcaption{Saturated v. unsaturated}
-\label{fig:clean_dirty_C}
-\end{subfigure}
-\begin{subfigure}{0.34\textwidth}
-\centering
-\includegraphics[width=\textwidth]{graphics/YCSB_WorkloadC_TimingA-freq_timeline.pdf}
-\bfcaption{CPU frequency over time.}
-\label{fig:C_frequency_shifts}
-\end{subfigure}
-\begin{subfigure}{0.32\textwidth}
-\centering
-\includegraphics[width=\textwidth,trim={5mm 10mm 0 0}]{graphics/C_latencies.pdf}
-\bfcaption{Saturated v. unsaturated latency.}
-\label{fig:C_governor_latencies}
-\end{subfigure}
-\vspace*{-3mm}
-\bfcaption{YCSB Workload C}
-\trimfigurespacing
-\end{figure*}
-
 \tinysection{No Frequency Scaling at Saturation} \label{no_saturation_scaling}
 However, the effects of frequency scaling only manifest themselves when CPUs are unsaturated -- something that would be missed by traditional database benchmarks.
 Figure~\ref{fig:clean_dirty_C} illustrates the effect of frequency scaling on database performance by injecting artificial delays in between queries.

Proposal/sections/description_testbed.tex

@@ -10,7 +10,7 @@ Phones will be purchased at least in pairs, providing a minimum of two physical
 Different types of phones will be purchased to vary hardware configurations, roughly corresponding to high end devices, low end devices, and average devices.  
 The physical testbed will consist of the phones, a hub connecting all of the phones, as well as control desktop that flashes the phones, controls experiments, logs data, and provides output.
 
-The second component of the testbed is the configuration manager, which will be deployed on the control desktop.  
+The second part of the testbed is the configuration manager, which will be deployed on the control desktop.  
 The control manager is responsible for deciding on software configurations as well as pairing software configurations with specific hardware configurations (i.e. devices in the testbed).  
 The control manager will leverage the configuration manager described in Sec.~\ref{sec:eval} and use the workload generator described in Sec.~\ref{sec:workload} to synthesize a software image to be flashed on a given device.
 

Proposal/sections/description_workload.tex

@@ -1,6 +1,6 @@
 %!TEX root = ../proposal.tex
 
-Workload and data generation is a critical part of any data management benchmark and forms the second component of the \PocketData infrastructure.
+Workload and data generation is a critical part of any data management benchmark and forms the third component of the \PocketData infrastructure.
 The server-class workloads that the database community is familiar with are typically high-volume streams of mostly homogeneous queries from a mix of simultaneous users.
 In contrast, each smartphone app has a dedicated database, and is typically used by only one user for a variety of tasks that are usually performed only one at a time.
 As a consequence, the database workload seen (see Figure~\ref{fig:C_frequency_shifts}) is bursty, variable, and noisy. 

Proposal/sections/implementation_plan.tex

@@ -10,7 +10,12 @@
 
 Figure~\ref{fig:timeline} shows our plans for implementing \PocketData, organized by infrastructure component.
 
-\tinysection{Component 1 (Runtime)} 
+\tinysection{Component 1 (Testbed)}
+In year 1, our primary aim is to first design and build the physical testbed and implement scripts that allow us to efficiently deploy test workloads to phones in bulk.  
+We will then develop a web-based job submission and monitoring process.
+Finally, as we develop a community around the infrastructure, we will extend the submission system into a fully featured portal allowing sharing of workloads, performance results, and more.
+
+\tinysection{Component 2 (Runtime)} 
 During the planning phase of this proposal, we developed and released a benchmarking toolkit.
 This toolkit makes it possible to obtain reproducible performance measurements for the set of test configurations that we have tested so far. 
 We plan to continue to expand the set of supported configurations to ensure that the runtime can produce reliable performance results.
@@ -18,7 +23,7 @@ During year 1, we plan to add support for a range of additional mobile data mana
 As the testbed platform comes online in year 1, and as we add new phones in years 2 and 3, we plan to thoroughly assess the runner's reliability on these new platforms.
 Finally, as the platform matures, we plan to explore performance variability across different operating system versions as well.
 
-\tinysection{Component 2 (Workloads)}
+\tinysection{Component 3 (Workloads)}
 During the planning phase of this proposal, we developed a technique for modeling mobile data management workloads based on query logs. 
 Using this technique, we should soon be able to define synthetic workload generators for major apps.
 To use these workloads, we also need to construct representative datasets: We aim to have at least a preliminary dataset generator completed midway through year 1.
@@ -26,13 +31,9 @@ At this point, we hope to be able to simulate at least a small number of apps.
 Through the rest of year 1 and into year 2, we aim to expand the library of apps that we can simulate reliably.
 Towards the end of year 2 and into year 3, we will generalize the workload and data generation processes to allow us to describe applications as mixtures of higher-level data management patterns.
 
-\tinysection{Component 3 (Packaging)}
+\tinysection{Component 4 (Packaging)}
 We plan to release a preliminary, beta version of the packaged infrastructure based on work done during the planning phase early in year 1.  After this, we aim for one release each year.
 
-\tinysection{Component 4 (Testbed)}
-In year 1, our primary aim is to first design and build the physical testbed and implement scripts that allow us to efficiently deploy test workloads to phones in bulk.  
-We will then develop a web-based job submission and monitoring process.
-Finally, as we develop a community around the infrastructure, we will extend the submission system into a fully featured portal allowing sharing of workloads, performance results, and more.
 
 \subsection{Risk Mitigation}
 We have already implemented prototypes of the software components of the infrastructure, so there is minimal risk of these components being infeasible.

Proposal/sections/research_focus.tex

@@ -97,7 +97,7 @@ PIs Kennedy and Ziarek have a joint research project, Just-in-Time Data Structur
 PI Kennedy is part of a collaborative research project with \textit{Shambhu Upadhyaya} (UB), \textit{Varun Chandola} (UB), \textit{Hung Ngo} (UB), and \textit{Long Nguyen} (UMich) that explores techniques for identifying insider attacks on databases (NSF-CNS-1409551).  
 Although the threat of insider attacks on mobile devices may be minimal, the specific methodology behind the work involves summarizing query logs by creating clusters of queries with similar ``intent.''
 The approach is showing promise for summarizing query logs from a corporate (banking) setting.
-Applying techniques developed from this proposal has been instrumental to our preliminary work on workload synthesis (Component 2), and shows that the approach can be generalized to domains other than Insider Threat detection (for example to the design of index selection tools).
+Applying techniques developed from this proposal has been instrumental to our preliminary work on workload synthesis (Component 3), and shows that the approach can be generalized to domains other than Insider Threat detection (for example to the design of index selection tools).
 
-PI Kul has a research project that focuses on detecting data leakage on mobile phones~\cite{kul2018trustcom}. The project explores the querying behavior changes of individual apps on a user's smartphone. The system models the drift in behavior by comparing probability distributions of the query workload features over time and uses this model to detect anomalies. 
-Our proposed infrastructure will provide us with query traces that (1) we can use in red-teaming tests, and (2) actual infected and anomalous apps create under real-world conditions.
+PI Kul has a research project that focuses on detecting data leakage on mobile phones~\cite{kul2018trustcom}. The project explores the querying behavior changes of individual apps on a user's smartphone. The system models behavioral drift by comparing probability distributions of the query workload features over time, for example to detect anomalies. 
+Our proposed infrastructure will provide query traces that (1) can be used in red-teaming tests, and (2) model actual infected and anomalous apps behaviors in real-world conditions.