doc/research2/src/intro.tex

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