Start port

[iotcloud.git] / non_block_chain / doc / iotcloud_informal / iotcloud.tex

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% Short Sectioned Assignment
% LaTeX Template
% Version 1.0 (5/5/12)
%
% This template has been downloaded from:
% http://www.LaTeXTemplates.com
%
% Original author:
% Frits Wenneker (http://www.howtotex.com)
%
% License:
% CC BY-NC-SA 3.0 (http://creativecommons.org/licenses/by-nc-sa/3.0/)
%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

%----------------------------------------------------------------------------------------
%   PACKAGES AND OTHER DOCUMENT CONFIGURATIONS
%----------------------------------------------------------------------------------------

\documentclass[paper=letter, fontsize=11pt]{scrartcl} % A4 paper and 11pt font size

\usepackage[T1]{fontenc} % Use 8-bit encoding that has 256 glyphs
\usepackage{fourier} % Use the Adobe Utopia font for the document - comment this line to return to the LaTeX default
\usepackage[english]{babel} % English language/hyphenation
\usepackage{amsmath,amsfonts,amsthm} % Math packages
\usepackage{graphicx}
\usepackage{lipsum} % Used for inserting dummy 'Lorem ipsum' text into the template
\usepackage{hyperref}
\usepackage{amssymb}
\usepackage{listings}
\usepackage[]{algorithm2e}
\usepackage{algpseudocode}
\usepackage{enumerate}
\usepackage[table,xcdraw]{xcolor}
\usepackage{sectsty} % Allows customizing section commands
\usepackage{float}
\usepackage{caption}
\usepackage{gensymb} % to used degree symbol 
\usepackage{siunitx} 
\usepackage{enumitem}

\usepackage[sc]{mathpazo}
\allsectionsfont{ \normalfont\scshape} % Make all sections the default font and small caps
\usepackage{fancyhdr} % Custom headers and footers
\pagestyle{fancyplain} % Makes all pages in the document conform to the custom headers and footers
\fancyhead{} % No page header - if you want one, create it in the same way as the footers below
\fancyfoot[L]{} % Empty left footer
\fancyfoot[C]{} % Empty center footer
\fancyfoot[R]{\thepage} % Page numbering for right footer
\renewcommand{\headrulewidth}{0pt} % Remove header underlines
\renewcommand{\footrulewidth}{0pt} % Remove footer underlines
\setlength{\headheight}{13.6pt} % Customize the height of the header

\numberwithin{equation}{section} % Number equations within sections (i.e. 1.1, 1.2, 2.1, 2.2 instead of 1, 2, 3, 4)
\numberwithin{figure}{section} % Number figures within sections (i.e. 1.1, 1.2, 2.1, 2.2 instead of 1, 2, 3, 4)
\numberwithin{table}{section} % Number tables within sections (i.e. 1.1, 1.2, 2.1, 2.2 instead of 1, 2, 3, 4)

\setlength\parindent{0pt} % Removes all indentation from paragraphs - comment this line for an assignment with lots of text

%----------------------------------------------------------------------------------------
%   TITLE SECTION
%----------------------------------------------------------------------------------------
\newcommand{\horrule}[1]{\rule{\linewidth}{#1}} % Create horizontal rule command with 1 argument of height

\title{ 
\normalfont \normalsize 
\textsc{University of California Irvine} \\  % Your university, school and/or department name(s)
\textsc{Prgramming Language Research Group} \\ [25pt]
\horrule{0.5pt} \\[0.4cm] % Thin top horizontal rule
\huge IoTCloud Version 2.0\\ % The assignment title
\horrule{2pt} \\[0.5cm] % Thick bottom horizontal rule
}

\author{Authors} % Your name


\date{\normalsize\today} % Today's date or a custom date

\begin{document}

\maketitle % Print the title




%---------------------------------------------------------------------------------------
% Custom Stuff
%---------------------------------------------------------------------------------------
\newcommand{\tab}[1]{\hspace{.2\textwidth}\rlap{#1}}




\section{\textbf{Introduction}}

\section{\textbf{Device Approach}}

\subsection{\textbf{Records}}
Each record has the following information included in it:
\begin{itemize}
    \item Machine ID of the device creating the record
    \item The vector clock using the largest clock values from each device it knows and its own largest clock value incremented by 1.
    \item Data payload
    \item HMAC of the record.
\end{itemize}
    
Records can be identified by the machine ID and the local machine clock, hereby referred to as the record ID.

\subsubsection{\textbf{Types of Payloads}}
The different types of record payloads are:
\begin{itemize}

    \item Transactions
        \begin{itemize}
            \item Contains:
            \begin{itemize}
                \item Transaction ID
                \item key-value pair gets (reads)
                \item A guard condition (boolean condition) that can be evaluated on the key-value gets.
                \item A set of key-value pairs that are to be updated if the guard condition is met.
                \item Can only get and set key-value pairs that are from 1 arbitrator.  Getting and/or setting key-value pairs from more than 1 arbitrator causes the transaction to be invalid and dead.
            \end{itemize}
        \end{itemize}
    \item Commit notifications
        \begin{itemize}
            \item Contains the commit of a single transaction, the whole transaction.
            \item There is 1 commit per transaction.
            \item Generated by the arbitrator for the set of key-value gets and sets in the transaction.
        \end{itemize}
    \item Abort notifications
        \begin{itemize}
            \item Contains a transaction ID of an aborted transaction and the machine ID of the device that created that transaction.
            \item Causes a transaction to be aborted, key-values not used in updates.
        \end{itemize}
    \item Data structure re-size notifications
        \begin{itemize}
            \item Contains new size of data structure (number of record allowed in the data structure or something like that).
        \end{itemize}
    \item Server sequence number confirmations.
        \begin{itemize}
            \item Contains a record ID and the server sequence number for that record that the server reported.
            \item Created by any device if that device finds a record with a server sequence number that does not have a server sequence number conformation yet.
        \end{itemize}
    \item Delete notifications
        \begin{itemize}
            \item Contain the server sequence number of the record that was deleted.
            \item Generated when a device deletes a record.
        \end{itemize}
    \item New Key notification
        \begin{itemize}
            \item Contains the name of a new key and the machine ID of the machine that is to arbitrate
            \item Generated when a device generates a new (never used) key-value pair.
        \end{itemize}
\end{itemize}

\subsection{\textbf{Pulling the data structure}}
To pull the latest version of the data structure the following is done:
\begin{enumerate}
    \item Make a pull request to the server and get all the records sent back.
    \item Separate the records by machine ID.
    \item For each machine ID, order the records based on that machine IDs clock within each of the records.
    \item Check the data structure for any malicious activity (discussed below)
\end{enumerate}

\subsection{\textbf{Updates}}
Updates take place as follows:
\begin{enumerate}
    \item A device pulls the latest version of the data structure.  If the device cannot pull the latest version because of network connectivity or some other issues then that device will just work using the local copy of the data structure it has.
    \item Check the pulled data structure for any malicious activity (as stated in a section below) if not done already.
    \item Check if any records in the current server need to be deleted (have delete notifications in data structure but the delete never took place), if so then delete them.
    \item Check that the size of the data structure will not exceed the max size when the new record is inserted.  If it does then prepare to delete records by inserting delete payloads in the new record (discussed below).
    \item The device makes a record as follows:
        \begin{enumerate}
            \item Adds its machine ID.
            \item Creates a vector clock using the largest clock values from each device it knows and its own largest clock value incremented by 1.
            \item Fill the record payload section with the transactions and other types of payloads.
            \item Fill the empty space of the record payload with server sequence number confirmations for records that have yet to have their server sequence numbers confirmed.
            \item Fill the empty space of the record payload with rescued key-value pairs, transactions, ext (Discussed later).
            \item Pad the record to be the same size for all records.
            \item Calculate the HMAC of the record and add that to the record
            \item Encrypt the record.
        \end{enumerate}
    \item Send the record to the server for insertion into the device's queue.
    \item Issue any server commands such as deletes to the server.
\end{enumerate}

If there is a connectivity issue then all the records will be held by the local device until connection is resumed then pushed to the server in the order which they occurred.  Also the device can only delete records for which there is a server sequence number.  At some point the device could run out of records to delete (it hasn't connected to the server in a while) in which case the device will not be able to delete any records.

\subsection{\textbf{Deletions}}
When deciding which records to delete the following is to be done:
\begin{enumerate}
    \item Order all the records in order based on their server sequence numbers
    \item Calculate the difference between the current size of the data structure and the minimum size of the data structure (lets call this $m$). Note: count newly inserted records towards the total size of the data structure if doing deletes while doing updates.
    \item Delete the oldest m records based on the ordering from step 1. 
    \begin{itemize}
        \item If a record to be deleted has live data in it then the whole data structure needs to be re-sized.
    \end{itemize}
\end{enumerate}

Note this makes that size of the data structure be bounded:
If there are $n$ devices and the data structure has a minimum size of $m$.  Then the max size of the data structure is given by $m + n -1$ for the case when all the devices make an update at the same time.   

\subsection{\textbf{Reading a key-value pair}}
When getting a key-value pair the following is done:
\begin{enumerate}
    \item A device pulls the latest version of the data structure.  If the device cannot pull the latest version because of network connectivity or some other issues then that device will just work using the local copy of the data structure it has.
    \item Check the pulled data structure for any malicious activity (as stated in a section below) if not done already.
    \item Find the transaction with the largest server sequence number that contains the key-value pair of interest (this is the latest value).
\end{enumerate}

\subsection{\textbf{Rescuing Transactions, Commits, Aborts, Ext}}
Data should be proactively rescued from the "oldest" records currently in the data structure.  Unused space in new records should be used to rescue data from old records so that when it comes time to delete the old records, there are no live pieces of data that need to be rescued.  When a piece of data is rescued, it is rescued with its vector clock as well (so that the time of that data can be saved).\\

When rescuing transactions and commits: only keep the key-value pair sets that do not have a newer key-value pair set (no other transaction/commits sets that key-value pair later in the future).  This means that transactions/commits can shrink in size.\\

When rescuing Key Value notifications: save the vector clock and the server sequence number of the notification in the rescued data.

When deciding which data to rescue the following is to be done:
\begin{enumerate}
    \item Order all the records in order based on their server sequence numbers
    \item Create an ordered list of currently live transactions, commits, aborts, ext from the oldest $n$ records from step one where the order is based on the age of the data (how old the record is).
    \item Randomly select from the list of live transactions, commits, aborts, ext to save.  Save as much as can fit in the current new record.  The random selection could give higher probability to transactions, commits, aborts, ext from records that are to be deleted sooner.
\end{enumerate}

\subsection{\textbf{Checking the Data Structure}}
Checking the data structure for consistency is done as follows:
\begin{enumerate}
    \item Verify that each record in the data structure has an HMAC that matches the data in the record.
    \item Verify that the oldest record the server sent has a server sequence number that is equal to or less than the server sequence number in the most recent delete notification (currently live delete notification) + 1.
    \item Make sure that for each device queue the difference between the vector clock value of the device queues clock is at most 1 between 2 consecutive messages for all records with server sequence numbers above the last deleted records server sequence numbers.
    \item Verify that no currently live data Structure re-size notification is smaller than the last known data structure size.  Data structure can only grow in size.
    \item Verify that all the server sequence numbers for the records that are currently present have unique numbers.
    \item Verify that all the server sequence numbers for the records have a difference of 1 (no gaps) for all records with server sequence numbers above the last deleted records server sequence numbers.
    \item Verify record server sequence numbers against the stated server sequence numbers in the server sequence number notification payloads (make sure the server is not changing the sequence number on the fly).
\end{enumerate}

\subsection{\textbf{The Arbitrator}}
The arbitrator can:
\begin{enumerate}
    \item Send Commits
    \item Send Aborts
\end{enumerate}

\subsubsection{\textbf{Commits}}
Commits have the following properties
\begin{itemize}
    \item Agree with the ordering of the server sequence numbers most of the time.
    \item Cannot commit an already aborted transaction.
    \item Commits state the ordering of key-value pairs.
    \item Can disagree with the ordering of server sequence numbers if arbitrator decides to do so.
    \item Should occur frequently as to make sure that the commit order matches the server sequence ordering as closely as possible (prevent large divergence of the 2 orderings)
\end{itemize}
    
\subsubsection{\textbf{Aborts}}

\begin{itemize}
    \item Aborts are used to show which transactions have been aborted based on the arbitrators decision.
    \item Aborts are considered live until an abort acknowledgement is presented.
\end{itemize}
 
\subsection{\textbf{Setting Up New Keys (Choosing the Arbitrator)}}
Setting up new keys is done as follows:
\begin{enumerate}
    \item Device wishes to generate new key
    \item Device inserts a New Key notification into the data structure.
\end{enumerate}
In the case where multiple devices are creating the same key, the key with the smallest vector clock is the only valid one.  In the case of a concurrent vector clock, the smallest server sequence number notification is the valid one.
    
\subsection{\textbf{Live Status}}
Live Status of entries:
\begin{enumerate}

    \item Delete notifications
        \begin{itemize}
            \item Live if it deleted the largest known server sequence number to be deleted (most recent delete).
        \end{itemize}
    
    \item Commit notifications
        \begin{itemize}
            \item Live until all the key-value pair sets in the transaction commit are dead.
                \begin{itemize}
                    \item key-value pairs are dead when a commit for a transaction that sets the same key-value pair occurs with a larger vector clock.
                \end{itemize}
        \end{itemize}
    
    \item Abort notifications
        \begin{itemize}
            \item Live until the device whos machine ID is in the abort notification makes an update to the data structure that contains a vector clock that is more in the future than the vector clock for this abort notification.
        \end{itemize}
    
    \item Data structure re-size notifications
        \begin{itemize}
            \item Live if it contains the largest target size of the data structure.
        \end{itemize}
    
    \item Server sequence number confirmations.
         \begin{itemize}
            \item Live until the record that this notification is reporting on is deleted.
        \end{itemize}
        
    \item Transactions
        \begin{itemize}
            \item Is dead if it is invalid (contains keys-values for multiple arbitrators)
            \item Live until a commit or abort notification for this transaction is generated.
        \end{itemize}
        
    \item New Key notification
        \begin{itemize}
            \item Is dead if there exists a New Key notification that has a server sequence number that is smaller and the same key name.
        \end{itemize}
    
\end{enumerate}

\section{\textbf{Server Approach}}

The servers view of the system is in terms of data slots where each data slot holds a single record, has a monotonically increasing number associated with it (server sequence number) for the record that currently is present in that data slot and can be set or deleted.  A server may have a finite amount of memory which it can partition into slots, reusing memory that newly deleted slots used to occupy.

There are 3 types of requests from a device that the server must respond to:
\begin{enumerate}
    \item Pull all current slots.
    \item Put a new record in a slot.
    \item Delete a slot.
\end{enumerate}

\subsection{\textbf{Pull all current slots}}
In this case the server will simply send back all active slots (slots that have data) in any order along with each slots server sequence number.  It is the job of the devices to order the slots.

\subsection{\textbf{Put a new record in a slot}}
In this case the server will:
\begin{enumerate}
    \item Receive a record data from a device.
    \item Put this record data in an empty slot.
    \item Assign the just received record the next number in the server sequence numbers.
\end{enumerate}
If more than 1 put request is made at the same time, the server is free to order the requests however it wishes.

\subsection{\textbf{Delete a slot}}
In this case the server will delete the data in the slot that has the server sequence number that matches the server sequence number in the delete request.  The server could delay the delete if it wishes (if it has plenty of space for new slots).

\section{\textbf{Data Structure Abstraction}}
This section outlines the data structure abstraction that is provided to the IoT application.  It is similar to a hash table key-value store.

Operations on the key-value store:
\begin{itemize}
    \item Put operation
    \item Get operation
    \item Check put status
    \item Create New Key Operation. 
\end{itemize}

\subsection{\textbf{Put Operation}}
This operation is described as follows:
\begin{itemize}
    \item Has the form:  put(Key-value-list, guard)
    \item Updates the key-value pairs listed in the key-value list.
    \item Has a boolean guard that is passed in that is able to read from keys that are associated with the same arbitrator as the keys being updated
    \item Returns an ID for this put (Transaction ID) or an error code if put is formatted incorrectly.
    \item Underlying action: Creates a transaction, creates a record and inserts that record in the data structure (doing deletes and other house keeping operations as needed).
\end{itemize}

\subsection{\textbf{Get Operation}}
\begin{itemize}
    \item Has the form:  get(key-name)
    \item Gets the current value of a key, also returns a machine ID for the arbitrator of that key.
    \item Underlying action:  Does a pull from the server and resolves the latest value for the specified key (as mentioned above).  Also does house keeping work like key rescue and sequence number notification as needed.
\end{itemize}

\subsection{\textbf{Check put status}}
\begin{itemize}
    \item Has the form of a callback.
    \item Notifies the application of an aborted transaction.
    \item Underlying action:  when an abort notification is received then the callback is called.  This is checked whenever this application makes changes to the data structure.
\end{itemize}

\subsection{\textbf{Create New Key Operation}}
\begin{itemize}
    \item Has the form:  createKey(key-name, machine-id)
    \item Creates a new key with an arbitrator at a specific machine ID
    \item Underlying action: Creates a new key notification, creates a record and inserts that record in the data structure (doing deletes and other house keeping operations as needed).
\end{itemize}



\section{\textbf{System Guarantees}}
\begin{itemize}
    \item Server cannot view data inside records
    \item Server cannot forge or modify or create any records
    \item Server cannot withhold any records
    \item Server cannot reorder records that could not have been ordered differently due to network latency
    \item Server cannot delete records unless told to do so.
    \item There will always be an obvious key-value pair that is the latest key value pair.
    \item The data structure is bounded in size such that $m$ is the minimum size of the data structure,  $n$ is the number of devices in the system and $s$ is the current size of the data structure: $m \leq s \leq (m+n-1)$
    \item Data structure can only grow when there are too may key-value pairs (and aborts) than what fit in the current data structure size within reason.
    \item No currently valid data can be lost by the system and go undetected.
    \item Devices can operate offline and re-sync with the system and get a consistent view of the system
    \item If the server tries to hold a device on an older version of the data structure, that device can eventually rejoin the main data structure without problems.
    \item Devices that have a transaction aborted will be able to be notified about the abort indefinitely (no time frame when notification must be accepted).
    \item Server cannot hold a device on an old version of the data structure and then move them to a newer version of the data structure without being detected (The server sequence numbers would reveal conflicts or gaps or both).

\end{itemize}
    
\section{\textbf{System Correctness}}
The measures of correctness for the system are divided by context and the different system operations as follows:
\begin{itemize}
    \item Data Integrity and Authentication
    \item Ordering of Records
    \item Data Structure Functions
\end{itemize}

\subsection{\textbf{Data Integrity and Authentication}}
The correctness of the cryptographic aspects of the data structure can be assumed provided that each record is encrypted with one of the client's key and the HMAC of each record does not indicate the data was tampered with. See section 2.7 for more details on how the data structure is verified.

\subsection{\textbf{Ordering of Records}}
The ordering of the records within the data structure is said to be correct if the total ordering derived from the records by the server sequence numbers does not conflict with the partial ordering derived from the vector clock.

\subsection{\textbf{Data Structure Functions}}
\subsubsection{\textbf{Put}}
\begin{itemize}
     \item From the client side the put operation is said to be correct if the function returns a valid transaction ID for a successful operation or an error code for an unsuccessful operation.
     \item From the server side the put operation is correct if the key-value pair changes only when the guard condition evaluates to true. The server should reply with either a transaction ID or and error code depending on the guard condition???
\end{itemize}

\subsubsection{\textbf{Get}}
\begin{itemize}
     \item For the client the get operation is correct if it returns the value and arbitrator machine ID that corresponds with the input key. Or and error message if no key-value pair exists with that key??? In addition, if any housekeeping work is involved, the get operation must only rescue transactions with a live status. See section 2.10 for details on Live Status.
     \item For the server a get operation is correct if the server returns a correctly ordered and untampered version of the data structure when the initial pull is done.
\end{itemize}

\subsubsection{\textbf{Create New Key}}
\begin{itemize}
     \item The client correctly created a new key if it inserts a properly formatted new key notification into the data structure with a valid arbitrator machine ID.
     \item The server is said to have correctly added a new key if a new key-value pair with the indicated arbitrator machine ID is inserted into the data structure. Or if it returns an error message for an invalid arbitrator machine ID??? What about collisions???
\end{itemize}


\end{document}