research2: architecture - send/recv datagram
[swifty.git] / doc / research1 / src / relatedwork.tex
1 %\section{\fontfamily{phv}\selectfont{\large{\bfseries{PREVIOUS RELATED WORK}}}}
2
3 The \emph{swift} protocol is currently implemented in user-space on top of UDP,  the thinnest wrapper over IP. It
4 entirely drops TCP's abstraction of sequential reliable data stream delivery - for \emph{swift} this is redundant. For
5 example, out-of-order data could still be saved and the same piece of data might always be received from another peer.
6 Being implemented over UDP, the protocol does its best to make every datagram self-contained. Due to the fact that the 
7 Internet is mostly used for disseminating content, the \emph{swift} aims at creating a single unified content-centric
8 transport protocol serving as a bridge language of content distribution. To implement that ultimate data cloud model,
9 the protocol has to unify use cases of data download, video-on-demand and live streaming. It must work in the settings
10 of client-server, peer-to-peer\cite{peer-to-peer}, CDN or peer-assisted networks, effectively blending those
11 architectures.
12
13
14 BitTorrent is also a peer-to-peer file sharing protocol used for distributing large amounts of data \cite{bittorrent}.
15 This protocol can distribute large files without large bandwidth consumption or cpu power. Rather than downloading a
16 file from a single source, the BitTorrent protocol allows users to join a "swarm" of hosts to download and upload from
17 each other simultaneously. Every file is divided into pieces. Just like in \emph{swift} protocol, when a hosts fully
18 received a piece, it can distribute it to other hosts. This way, the task of distributing a file is supported by all who
19 need that file.
20
21 In BitTorrent, every piece has a cryptographic hash attached in the torrent descriptor. When an entire piece is
22 received, the host recalculate the hash in order to verify the authenticity of the actual piece. The integrity of the
23 data is checked in the same manner also for \emph{swift} protocol, but in this case the hash is send along with the
24 useful data.  
25
26 LEDBAT\cite{ledbat}, \cite{ledbat2} is an experimental delay-based congestion control algorithm. It's main goal is to
27 utilize the available bandwidth on an end-to-end path while limiting the consequent increase in queueing delay on the
28 path. LEDBAT uses changes in one-way delay measurements to limit congestion induced in the network by the LEDBAT flow.
29 LEDBAT is designed largely for use by background bulk-transfer applications. It is designed to be no more aggressive
30 than TCP congestion control and yields in the presence of competing TCP flows, thus reducing interference with the
31 network performance of the competing flows. The \emph{swift} protocols relies on LEDBAT for congestion control support.