Update research2: finish intro

diff --git a/doc/research2/img/arch1.pdf b/doc/research2/img/arch1.pdf
new file mode 100644 (file)
index 0000000..eba161b
Binary files /dev/null and b/doc/research2/img/arch1.pdf differ

diff --git a/doc/research2/img/tree.png b/doc/research2/img/tree.png
deleted file mode 100644 (file)
index 6a34747..0000000
Binary files a/doc/research2/img/tree.png and /dev/null differ

diff --git a/doc/research2/src/intro.tex b/doc/research2/src/intro.tex
index e5359e0..a2f3903 100644 (file)
--- a/doc/research2/src/intro.tex
+++ b/doc/research2/src/intro.tex
@@ -15,17 +15,44 @@ infrastructure of a particular corporation. These are the reasons of the \emph{s
 primary goal to act as a generic content-centric multiparty transport protocol that allows seamless, effortless data
 dissemination on the big cloud represented by the Internet.
 
 primary goal to act as a generic content-centric multiparty transport protocol that allows seamless, effortless data
 dissemination on the big cloud represented by the Internet.
 

-// TODO - swift description paragraph
+\subsection{Swift Description}

 
 

-\textbf{Contribution}. // TODO
+Most features of the \emph{swift} protocol are defined by its function as a content-centric multiparty transport 
+protocol. A significant difference between \emph{swift} and the TCP protocol is that TCP possesses no information
+regarding what data it is dealing with, as the data is passed from the user-space, while the \emph{swift} protocol has
+data fixed in advance and many peers participate in distributing the same data. Because of this and the fact that for
+\emph{swift} the order of delivery is of little importance and unreliability is naturally compensated for by redundancy,
+it entirely drops TCP's abstraction of sequential reliable data stream delivery. For example, out-of-order data could
+still be saved and the same piece of data might always be received from another peer.
+
+Being implemented over UDP, the protocol does its best to make every datagram self-contained so each datagram could be 
+processed separately and a loss of one datagram must not disrupt the flow. Thus, a datagram carries zero or more
+messages, and neither messages nor message interdependencies should span over multiple datagrams. 
+
+The verification of data pieces is realize using Merkle hash trees\cite{merkle}, \cite{merkle-ext}. That means that all
+hashes necessary for verifying data integrity needs to be put into the same datagram as the data. For both use cases,
+streaming and downloading, an unified  integrity checking scheme that works down to the level of a single datagram is
+developed. As a general rule, the sender should append to the data some meta-data represented by the necessary hashes
+for the data verification. While some optimistic optimizations are definitely possible, the receiver should drop data if
+it is impossible to verify it. Before sending a packet of data to the receiver, the sender inspects the receiver's
+previous acknowledgments to derive which hashes the receiver already has for sure. 
+
+The data is acknowledged in terms of binary intervals, with the base interval of 1KB "packet". As a result, every 
+single packet is acknowledged logarithmic number of times. This mechanism provides some necessary redundancy of the
+acknowledgements and sufficiently compensates the unreliability of the datagrams. 
+
+The only function of TCP that is also critical for \emph{swift} is the congestion control. To facilitate delay-based 
+congestion control an acknowledgment contains besides the dimension of the file received from its addressee a timestamp.
+
+
+\textbf{Contribution}. Our main objective is to integrate \emph{swift} as a transport protocol in the Linux kernel 
+networking stack. This will provide notable performance improvement regarding data transfer. We intend to do this with 
+minimal intrusion effect in the Linux kernel and also to change as little as possible the current \emph{swift} 
+implementation. Another goal is to provide a transparent API between the kernel and the user space. A developer will use 
+a socket-like interface when building an application on top of the \emph{swift} protocol. In order to achieve this goal
+we have implemented an intermediary step. We have simulated the kernel part in the user-space using raw sockets. This 
+has the advantage of providing means to have modular functionality tests.

 
 

-\begin{comment}
-Our main objective is to integrate \emph{swift} as a transport protocol in the Linux kernel
-networking stack. This will provide notable performance improvement regarding data transfer. We intend to do this with
-minimal intrusion effect in the Linux kernel and also to change as little as possible the current \emph{swift}
-implementation. Another goal is to provide a transparent API between the kernel and the user space. A developer will use
-a socket-like interface when building an application on top of the \emph{swift} protocol.
-\end{comment}

 
 \textbf{Outline}. The rest of the paper is organized as follows. In section \ref{sec:preliminarywork} we discuss some
 previous approaches in designing the system with their sthrengths and weaknesess. In section \ref{sec:arch}
 
 \textbf{Outline}. The rest of the paper is organized as follows. In section \ref{sec:preliminarywork} we discuss some
 previous approaches in designing the system with their sthrengths and weaknesess. In section \ref{sec:arch}

diff --git a/doc/research2/src/preliminarywork.tex b/doc/research2/src/preliminarywork.tex
index 7d2285e..6e9c9f3 100644 (file)
--- a/doc/research2/src/preliminarywork.tex
+++ b/doc/research2/src/preliminarywork.tex
@@ -10,13 +10,10 @@ For the integrity check the swift protocol relies on Merkle hash tree. Keeping t
 not scalable. The Internet content is too large to be stored in kernel. Even if the tree retains only hashes of the data
 disseminated, the space is insufficient.
 
 not scalable. The Internet content is too large to be stored in kernel. Even if the tree retains only hashes of the data
 disseminated, the space is insufficient.
 

+\image[scale=0.4]{img/arch1.pdf}{img:arch1}{Previous Architecture}

 
 

-
-The second approach of the swift implementation is represent in the \labelindexref{Figure}{img:tree}.
-
-\image[scale=0.45]{img/tree}{img:tree}{Tree}
-
-The swift transport should have been a new kernel interface allowing the creation of specialized swift sockets. It
+The second approach of the swift implementation is represent in the \labelindexref{Figure}{img:arch1}. The swift transport 
+  should have been a new kernel interface allowing the creation of specialized swift sockets. It

 should have implemented the multiparty protocol allowing piece transport to/from other hosts in a peer-to-peer fashion.
 
 That implementation should have had specialized "request queues", metadata queues, to/from user space.  Specialized
 should have implemented the multiparty protocol allowing piece transport to/from other hosts in a peer-to-peer fashion.
 
 That implementation should have had specialized "request queues", metadata queues, to/from user space.  Specialized