--- /dev/null
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 TRANSITIONAL//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html>
+
+<head>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+ <title>swift: the multiparty transport protocol</title>
+ <link rel="stylesheet" href="style.css" type="text/css">
+ <script src="http://code.jquery.com/jquery-latest.js"></script>
+ <script>
+ $(document).ready(function(){
+ $("div.fold>h4, div.fold>h3, div.fold>h2").click(function () {
+ $("div.fold>p, div.fold>ul, div.fold>div").hide("fast");
+ $(this).siblings().each(
+ function(){
+ $(this).show("normal");
+ }
+ );
+ });
+ });
+ </script>
+</head>
+<body>
+
+<div>
+ <img id=logo src="apusapus.png"/>
+ <h1><i>swift:</i> the multiparty transport protocol</h1>
+
+ <div id='motto'>Turn the Net into a single data Cloud!</div>
+
+ <div> <h2>Ideas</h2>
+ <p>As <a href="http://en.wikipedia.org/wiki/Content-centric_networking">
+ wise people say</a>, the Internet was initially built for
+ remotely connecting scientists to expensive supercomputers (whose computing
+ power was comparable to modern cell phones). Thus, they supported the abstraction
+ of <i>conversation</i>. Currently, the Internet is mostly used for disseminating
+ content to the masses, which mismatch definitely creates some problems.</p>
+
+ <p>The <i>swift</i> protocol is a content-centric multiparty transport
+ protocol. Basically, it answers one and only one question: <i>"Here is a
+ <a href="http://en.wikipedia.org/wiki/Hash_function">hash</a>!
+ Give me data for it!"</i> A bit oversimplifying, it might be understood as
+ <a href="http://en.wikipedia.org/wiki/BitTorrent">BitTorrent</a>
+ at the <a href="http://en.wikipedia.org/wiki/Transport_Layer">
+ transport layer</a>. Ultimately, it aims at the abstraction of the Internet
+ as a single big data <a href="http://en.wikipedia.org/wiki/Cloud_computing">
+ Cloud</a>. Such entities as storage, servers and connections are abstracted
+ away and are virtually invisible at the API layer. The data is received
+ from whatever source available and data integrity is checked
+ cryptographically with <a href="http://en.wikipedia.org/wiki/Hash_tree">
+ Merkle hash trees</a>.</p>
+
+ <p>An old Unix adage says: "free memory is wasted memory". Once a
+ computer is powered on, there is no benefit in keeping some memory
+ unoccupied. We may extend this principle a bit further:
+ <ul>
+ <li>free bandwidth is wasted bandwidth;
+ <li>free storage is wasted storage.
+ </ul>
+ Unless your power budget is really tight, there is no sense in conserving
+ either. Thus, instead of putting emphasis on reciprocity and incentives
+ we focus on ligther-footprint code,
+ <a href="http://tools.ietf.org/wg/ledbat/">non-intrusive</a>
+ <a href="http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithm">
+ congestion control</a> and automatic disk space management.
+ </p>
+
+ <p>Currently, most parts of the protocol/library are implemented, pass
+ basic testing and successfully transfer data on real networks.
+ After more scrutinized testing, the protocol and the library are expected
+ to be real-life-ready in March'10.
+ </p>
+ </div>
+
+ <div id='design'> <h2>Design of the protocol</h2>
+
+ <p>Most features of the protocol are defined by its function of
+ content-centric multiparty transport protocol. It entirely drops the TCP's
+ abstraction of sequential reliable data stream delivery as it is redundant in
+ our case. For example, out-of-order data could still be saved and the same
+ piece of data might be always received from another peer.
+ Being implemented over UDP, the protocol does its best to make
+ every datagram self-contained.
+ In general, cutting of unneeded functions and aggressive layer collapsing
+ greatly simplified the protocol, compared to e.g. the BitTorrent+TCP stack.</p>
+
+ <div class='fold'> <h3>Atomic datagrams, not data stream</h3>
+ <p>To achieve per-datagram flexibility of data flow and also to adapt to
+ the unreliable medium (UDP, and, ultimately, IP), the protocol was built
+ around the abstraction of atomic datagrams.
+ Ideally, once received, a datagram is either
+ immediately discarded or permanently accepted, ready to be forwarded to
+ other peers.
+ For the sake of flexibility, most of the protocol's messages
+ are optional. It also has no "standard" header. Instead, each datagram
+ is a concatenation of zero or more messages. No message ever spans two
+ datagrams. Except for the data pieces themselves, no message is
+ acknowledged, as thus, not guaranteed to be delivered.</p>
+ </div>
+
+ <div class='fold'> <h3>Scale-independent unit system</h3>
+ <p>To avoid a multilayered request/acknowledgement system, when every
+ next layer does basically the same, but for bigger chunks of data, as
+ it is the case with BitTorrent+TCP packet-block-piece-file-torrent
+ stacking, <i>swift</i> employs a scale-independent acknowledgement/
+ request system, where data is measured by aligned power-of-2 intervals
+ (so called bins). All acknowledgements and requests are done in terms
+ of bins.</p>
+ </div>
+
+ <div class='fold'> <h3>Datagram-level integrity checks</h3>
+ <p><i>swift</i> builds Merkle hash trees down to every single packet
+ (1 kilobyte of data). Once data is transmitted, all uncle hashes
+ necessary for verification are prepended to the same datagram.
+ As the receiver constantly remembers old hashes, the average number
+ of "new" hashes, which have to be transmitted is small,
+ normally around 1 per packet of data.</p>
+ </div>
+
+ <div class='fold'> <h3>NAT traversal by design</h3>
+ <p>The only method of peer discovery in <i>swift</i> is
+ <a href="http://en.wikipedia.org/wiki/Peer_exchange">PEX</a>:
+ a third peer initiates a connection between two of its contacted peers.
+ The protocol's handshake is engineered to perform simple NAT hole
+ punching transparently, in case that is needed.
+ </p>
+ </div>
+
+ <div class='fold'> <h3>Push AND pull</h3>
+ <p>The protocol allows both for PUSH (sender decides what to send) and
+ PULL (receiver explicitly requests the data). PUSH is normally used as
+ a fallback if PULL fails; also, the sender may ignore requests and send
+ any data it finds convenient to send. Merkle hash trees allow this
+ flexibility without causing security implications.</p>
+ </div>
+
+ <div class='fold'> <h3>No transmission metadata</h3>
+ <p></p>
+ </div>
+ </div>
+
+ <div> <h2>Specifications and documentation</h2>
+ <p>
+ <ul>
+ <li><a href="http://github.com/gritzko/swift/raw/master/doc/swift-protocol.txt">
+ internet draft style technical description</a>
+ <li><a href="">article</a>
+ </ul>
+ </p>
+ </div>
+
+ <div> <h2>The code</h2>
+ <ul>
+ <li><a href="swift.tar.gz">fairly recent tarball</a>
+ <li><a href="http://github.com/gritzko/swift"><i>swift</i> at github</a>
+ </ul>
+ </div>
+
+ <div> <h2>Frequently asked questions</h2>
+
+ <div class="fold"> <h3>Well, why "swift"?</h3>
+ <p>That name served well to many other protocols; we hope it will serve well to ours.
+ You may count it as a meta-joke. The original name for the protocol was "VicTorrent".
+ We also insist on lowercase italic <i>"swift"</i> to keep the name formally unique
+ (for some definition of unique).</p>
+ </div>
+
+ <div> <h3>How is it different from... </h3>
+
+ <div class='fold'><h4>...TCP?</h4>
+ <p>TCP emulates reliable in-order delivery ("data pipe") over
+ chaotic unreliable multi-hop networks. TCP has no idea what data it is dealing
+ with, as the data is passed from the userspace.
+ In our case, the data is fixed in advance and many peers participate in
+ distributing the same data. Orderness of delivery is of little importance and
+ unreliability is naturally compensated by redundance.
+ Thus, many functions of TCP turn out to be redundant.
+ The only function of TCP that is also critical for <i>swift</i> is the congestion
+ control, but... we need our own custom congestion control! Thus, we did not use
+ TCP.</p>
+ <p>That led both to hurdles and to some savings. As one example, every TCP
+ connection needs to maintain buffers for the data that has left the sender's userspace, but
+ did not yet arrive at the receiver's userspace. As we know that we are dealing
+ with the same fixed data, we don't need to maintain per-connection buffers.
+ </p>
+ </div>
+
+ <div class='fold'><h4>...UDP?</h4>
+ <p>UDP, which is the thinniest wrapper around <a href="http://en.wikipedia.org/wiki/IPv4">
+ IP</a>, is our choise of underlying protocol. From the standpoint of ideology, a
+ transport protocol should be implemented over IP, but unfortunately that causes
+ some chicken-and-egg problems, like a need to get into the kernel to get deployments,
+ and a need to get deployments to be accepted into the kernel.
+ UDP is also quite nice in regard to NAT penetration.</p>
+ </div>
+
+ <div class='fold'><h4>...BitTorrent?</h4>
+ <p>BitTorrent is an application-level protocol and quite a heavy one. We focused
+ on fitting our protocol into the restrictions of the transport layer, assuming
+ that the protocol might eventually be included into operating system kernels.
+ For example, we stripped the protocol of any transmission's metadata (the
+ .torrent file); leaving a file's root hash as the only parameter.</p>
+ </div>
+
+ <div class='fold'><h4>...µTorrent's µTP?</h4>
+ <p>Historically, BitTorrent gained lots of adaptations to its underlying
+ transport. First and foremost, TCP is unable to prioritize traffic, so BitTorrent
+ needed to coerce users somehow to tolerate inconviniences of seeding. That caused
+ tit4tat and, to significant degree, rarest-first. Another example is the 4
+ upload slots limitation. (Well, apparently, some architectural decisions in
+ BitTorrent were dictated by oddities Windows 95, but... never mind.)
+ Eventually, BitTorrent developers came to the conclusion that not annoying
+ the user in the first place is probably a better stimulus. So they came up with
+ the <a href='http://www.ietf.org/dyn/wg/charter/ledbat-charter.html'>LEDBAT</a>
+ congestion control algorithm (Low Extra Delay Background Transport).
+ LEDBAT allows a peer to seed without interfering with the regular traffic
+ (in plain words, without slowing down the browser).
+ To integrate the novel congestion control algorithm into BitTorrent incrementally,
+ BitTorrent Inc had to develop TCP-alike transport named
+ <a href="http://en.wikipedia.org/wiki/Micro_Transport_Protocol">µTP</a>.
+ The <i>swift</i> project (then named VicTorrent) was started when we tried to understand
+ what happens if we'll strip BitTorrent of any Win95-specific, TCP-specific
+ or Python-specific workarounds. As it turns out, not much was left.
+ </p>
+ </div>
+
+ <div class='fold'><h4>...Van Jacobson's CCN?</h4>
+ <p><a href="http://www.parc.com/about/people/88/van-jacobson.html">Van Jacobson's</a>
+ team in PARC is doing exploratory research on
+ <a href="http://en.wikipedia.org/wiki/Content-centric_networking">content-centric
+ networking</a>. While BitTorrent works at layer 5 (application), we go to layer 4 (transport),
+ PARC people are bold enough to go to layer 3 and to propose a complete replacement
+ for the entire TCP/IP world. That is certainly a compelling vision, but we focus
+ on near future (<10 years); while <a href="http://www.ccnx.org/">CCNx</a> is a
+ much more ambitious rework.</p>
+ </div>
+
+ <div class='fold'><h4>...DCCP?</h4>
+ <p>This question arises quite frequently as DCCP is a congestion-controlled datagram
+ transport. The option of implementing <i>swift</i> over
+ <a href="http://en.wikipedia.org/wiki/DCCP">DCCP</a> was considered,
+ but the inconvinience of working with an esoteric transport was not compensated by the
+ added value of DCCP, which is limited to one mode of congestion control being readily
+ implemented.
+ Architectural restrictions imposed by DCCP were also found to be a major inconvenience.
+ Last but not least, currently only Linux supports DCCP at the kernel level.</p>
+ </div>
+
+ <div class='fold'><h4>...SCTP?</h4>
+ <p></p>
+ </div>
+
+ </div>
+
+ <div class='fold'> <h2>Who we are</h2>
+ <p>
+ <ul>
+ <li> <a href="http://p2p-next.org/">P2P-Next Project</a>, EU 7th Framework Program
+ <li> <a href="http://ewi.tudelft.nl">Delft University of Technology</a> EWI PDS
+ <li> <a href="http://www.st.ewi.tudelft.nl/~pouwelse/">Dr. Johan Pouwelse</a>
+ <li> <a href="http://www.tribler.org/trac/wiki/VictorGrishchenko">
+ Dr. Victor Grishchenko</a>
+ </ul>
+ </p>
+ </div>
+
+ <div class=fold> <h2>Contacts&feedback</h2>
+ <p><a href="mailto:victor.grishchenko@gmail.com">mail us</a></p>
+ <p>subscribe to a mailing list</p>
+ </div>
+
+</body>
+</html>
\ No newline at end of file
+++ /dev/null
-.\"Modified from man(1) of FreeBSD, the NetBSD mdoc.template, and mdoc.samples.\r
-.\"See Also:\r
-.\"man mdoc.samples for a complete listing of options\r
-.\"man mdoc for the short list of editing options\r
-.\"/usr/share/misc/mdoc.template\r
-.Dd 3/6/09 \" DATE \r
-.Dt serp++ 1 \" Program name and manual section number \r
-.Os Darwin\r
-.Sh NAME \" Section Header - required - don't modify \r
-.Nm serp++,\r
-.\" The following lines are read in generating the apropos(man -k) database. Use only key\r
-.\" words here as the database is built based on the words here and in the .ND line. \r
-.Nm Other_name_for_same_program(),\r
-.Nm Yet another name for the same program.\r
-.\" Use .Nm macro to designate other names for the documented program.\r
-.Nd This line parsed for whatis database.\r
-.Sh SYNOPSIS \" Section Header - required - don't modify\r
-.Nm\r
-.Op Fl abcd \" [-abcd]\r
-.Op Fl a Ar path \" [-a path] \r
-.Op Ar file \" [file]\r
-.Op Ar \" [file ...]\r
-.Ar arg0 \" Underlined argument - use .Ar anywhere to underline\r
-arg2 ... \" Arguments\r
-.Sh DESCRIPTION \" Section Header - required - don't modify\r
-Use the .Nm macro to refer to your program throughout the man page like such:\r
-.Nm\r
-Underlining is accomplished with the .Ar macro like this:\r
-.Ar underlined text .\r
-.Pp \" Inserts a space\r
-A list of items with descriptions:\r
-.Bl -tag -width -indent \" Begins a tagged list \r
-.It item a \" Each item preceded by .It macro\r
-Description of item a\r
-.It item b\r
-Description of item b\r
-.El \" Ends the list\r
-.Pp\r
-A list of flags and their descriptions:\r
-.Bl -tag -width -indent \" Differs from above in tag removed \r
-.It Fl a \"-a flag as a list item\r
-Description of -a flag\r
-.It Fl b\r
-Description of -b flag\r
-.El \" Ends the list\r
-.Pp\r
-.\" .Sh ENVIRONMENT \" May not be needed\r
-.\" .Bl -tag -width "ENV_VAR_1" -indent \" ENV_VAR_1 is width of the string ENV_VAR_1\r
-.\" .It Ev ENV_VAR_1\r
-.\" Description of ENV_VAR_1\r
-.\" .It Ev ENV_VAR_2\r
-.\" Description of ENV_VAR_2\r
-.\" .El \r
-.Sh FILES \" File used or created by the topic of the man page\r
-.Bl -tag -width "/Users/joeuser/Library/really_long_file_name" -compact\r
-.It Pa /usr/share/file_name\r
-FILE_1 description\r
-.It Pa /Users/joeuser/Library/really_long_file_name\r
-FILE_2 description\r
-.El \" Ends the list\r
-.\" .Sh DIAGNOSTICS \" May not be needed\r
-.\" .Bl -diag\r
-.\" .It Diagnostic Tag\r
-.\" Diagnostic informtion here.\r
-.\" .It Diagnostic Tag\r
-.\" Diagnostic informtion here.\r
-.\" .El\r
-.Sh SEE ALSO \r
-.\" List links in ascending order by section, alphabetically within a section.\r
-.\" Please do not reference files that do not exist without filing a bug report\r
-.Xr a 1 , \r
-.Xr b 1 ,\r
-.Xr c 1 ,\r
-.Xr a 2 ,\r
-.Xr b 2 ,\r
-.Xr a 3 ,\r
-.Xr b 3 \r
-.\" .Sh BUGS \" Document known, unremedied bugs \r
-.\" .Sh HISTORY \" Document history if command behaves in a unique manner
\ No newline at end of file
projects / swift-upb.git / commitdiff
