doc/research2/src/intro.tex

   1 %\section{\fontfamily{phv}\selectfont{\large{\bfseries{INTRODUCTION}}}}
   2
   3 The \emph{swift} protocol is a generic multiparty transport protocol. Its mission is to disseminate content among a
   4 swarm of peers. Basically, it answers one and only one request: \emph{'Here is a hash! Give me data for it!'}. Such
   5 entities as storage, servers and connections are abstracted and are virtually invisible at the API layer. Given a hash,
   6 the data is received from whatever source available and data integrity is checked cryptographically with Merkle hash
   7 trees.
   8
   9 If you need some data it is somewhat faster and/or cheaper downloading it from a nearby well-provisioned replica, but
  10 on the other hand, this process requires that multiple parties (e.g. consumers, the data sources, CDN
  11 sites\cite{cdnwiki} , mirrors, peers) have to be coordinate. As the Internet content  is in a continuous increasing
  12 nowadays, the overhead of peer/replica coordination becomes higher then the mass of the download itself. Thus, the niche
  13 for multiparty transfers expands. Still, current, relevant technologies are tightly coupled to a single use case or even
  14 infrastructure of a particular corporation. These are the reasons of the \emph{swift} protocol appearance with its
  15 primary goal to act as a generic content-centric multiparty transport protocol that allows seamless, effortless data
  16 dissemination on the big cloud represented by the Internet.
  17
  18 \subsection{Swift Description}
  19
  20 Most features of the \emph{swift} protocol are defined by its function as a content-centric multiparty transport
  21 protocol. A significant difference between \emph{swift} and the TCP protocol is that TCP possesses no information
  22 regarding what data it is dealing with, as the data is passed from the user-space, while the \emph{swift} protocol has
  23 data fixed in advance and many peers participate in distributing the same data. Because of this and the fact that for
  24 \emph{swift} the order of delivery is of little importance and unreliability is naturally compensated for by redundancy,
  25 it entirely drops TCP's abstraction of sequential reliable data stream delivery. For example, out-of-order data could
  26 still be saved and the same piece of data might always be received from another peer.
  27
  28 Being implemented over UDP, the protocol does its best to make every datagram self-contained so each datagram could be
  29 processed separately and a loss of one datagram must not disrupt the flow. Thus, a datagram carries zero or more
  30 messages, and neither messages nor message interdependencies should span over multiple datagrams.
  31
  32 The verification of data pieces is realize using Merkle hash trees\cite{merkle}, \cite{merkle-ext}. That means that all
  33 hashes necessary for verifying data integrity needs to be put into the same datagram as the data. For both use cases,
  34 streaming and downloading, an unified  integrity checking scheme that works down to the level of a single datagram is
  35 developed. As a general rule, the sender should append to the data some meta-data represented by the necessary hashes
  36 for the data verification. While some optimistic optimizations are definitely possible, the receiver should drop data if
  37 it is impossible to verify it. Before sending a packet of data to the receiver, the sender inspects the receiver's
  38 previous acknowledgments to derive which hashes the receiver already has for sure.
  39
  40 The data is acknowledged in terms of binary intervals, with the base interval of 1KB "packet". As a result, every
  41 single packet is acknowledged logarithmic number of times. This mechanism provides some necessary redundancy of the
  42 acknowledgements and sufficiently compensates the unreliability of the datagrams.
  43
  44 The only function of TCP that is also critical for \emph{swift} is the congestion control. To facilitate delay-based
  45 congestion control an acknowledgment contains besides the dimension of the file received from its addressee a timestamp.
  46
  47
  48 \textbf{Contribution}. Our main objective is to integrate \emph{swift} as a transport protocol in the Linux kernel
  49 networking stack. This will provide notable performance improvement regarding data transfer. We intend to do this with
  50 minimal intrusion effect in the Linux kernel and also to change as little as possible the current \emph{swift}
  51 implementation. Another goal is to provide a transparent API between the kernel and the user space. A developer will use
  52 a socket-like interface when building an application on top of the \emph{swift} protocol. In order to achieve this goal
  53 we have implemented an intermediary step. We have simulated the kernel part in the user-space using raw sockets. This
  54 has the advantage of providing means to have modular functionality tests.
  55
  56
  57 \textbf{Outline}. The rest of the paper is organized as follows. In section \ref{sec:preliminarywork} we discuss some
  58 previous approaches in designing the system with their sthrengths and weaknesess. In section \ref{sec:arch}
  59  presents our current approach to integrate the \emph{swift} protocol as a transport layer protocol into the Linux
  60 kernel. Section \ref{sec:rawsock} presents a preliminary implementation using raw socktes that prepares the ground for
  61 the final stage of the project.  We describe our testing scenariou in detail in section \ref{sec:testing}. Section
  62 \ref{sec:summary} concludes the article and refers to future work.