Merge commit 'sjmurdoch/xxx-using-spdy'

doc/spec/proposals/ideas/xxx-using-spdy.txt

@@ -0,0 +1,143 @@
+Filename: xxx-using-spdy.txt
+Title: Using the SPDY protocol to improve Tor performance
+Author: Steven J. Murdoch
+Created: 03-Feb-2010
+Status: Draft
+Target:
+
+1. Overview
+
+   The SPDY protocol [1] is an alternative method for transferring
+   web content over TCP, designed to improve efficiency and
+   performance. A SPDY-aware browser can already communicate with
+   a SPDY-aware web server over Tor, because this only requires a TCP
+   stream to be set up. However, a SPDY-aware browser cannot
+   communicate with a non-SPDY-aware web server. This proposal
+   outlines how Tor could support this latter case, and why it
+   may be good for performance.
+
+2. Motivation
+
+   About 90% of Tor traffic, by connection, is HTTP [2], but
+   users report subjective performance to be poor. It would
+   therefore be desirable to improve this situation. SPDY was
+   designed to offer better performance than HTTP, in
+   high-latency and/or low-bandwidth situations, and is therefore
+   an option worth examining.
+
+   If a user wishes to access a SPDY-enabled web server over Tor,
+   all they need to do is to configure their SPDY-enabled browser
+   (e.g. Google Chrome) to use Tor. However, there are few
+   SPDY-enabled web servers, and even if there was high demand
+   from Tor users, there would be little motivation for server
+   operators to upgrade, for the benefit of only a small
+   proportion of their users.
+
+   The motivation of this proposal is to allow only the user to
+   install a SPDY-enabled browser, and permit web servers to
+   remain unmodified. Essentially, Tor would incorporate a proxy
+   on the exit node, which communicates SPDY to the web browser
+   and normal HTTP to the web server. This proxy would translate
+   between the two transport protocols, and possibly perform
+   other optimizations.
+
+   SPDY currently offers five optimizations:
+
+   1) Multiplexed streams:
+      An unlimited number of resources can be transferred
+      concurrently, over a single TCP connection.
+
+   2) Request prioritization:
+      The client can set a priority on each resource, to assist
+      the server in re-ordering responses.
+
+   3) Compression:
+      Both HTTP header and resource content can be compressed.
+
+   4) Server push:
+      The server can offer the client resources which have not
+      been requested, but which the server believes will be.
+
+   5) Server hint:
+      The server can suggest that the client request further
+      resources, before the main content is transferred.
+
+   Tor currently effectively implements (1), by being able to put
+   multiple streams on one circuit. SPDY however requires fewer
+   round-trips to do the same. The other features are not
+   implemented by Tor. Therefore it is reasonable to expect that
+   a HTTP <-> SPDY proxy may improve Tor performance, by some
+   amount.
+
+   The consequences on caching need to be considered carefully.
+   Most of the optimizations SPDY offers have no effect because
+   the existing HTTP cache control headers are transmitted without
+   modification. Server push is more problematic, because here
+   the server may push a resource that the client already has.
+
+3. Design outline
+
+   One way to implement the SPDY proxy is for Tor exit nodes to
+   advertise this capability in their descriptor. The OP would
+   then preferentially select these nodes when routing streams
+   destined for port 80.
+
+   Then, rather than sending the usual RELAY_BEGIN cell, the OP
+   would send a RELAY_BEGIN_TRANSFORMED cell, with a parameter to
+   indicate that the exit node should translate between SPDY and
+   HTTP. The rest of the connection process would operate as
+   usual.
+
+   There would need to be some way of elegantly handling non-HTTP
+   traffic which goes over port 80.
+
+4. Implementation status
+
+   SPDY is under active development and both the specification
+   and implementations are in a state of flux. Initial
+   experiments with Google Chrome in SPDY-mode and server
+   libraries indicate that more work is needed before they are
+   production-ready. There is no indication that browsers other
+   than Google Chrome will support SPDY (and no official
+   statement as to whether Google Chrome will eventually enable
+   SPDY by default).
+
+   Implementing a full SPDY proxy would be non-trivial. Stream
+   multiplexing and compression are supported by existing
+   libraries and would be fairly simple to implement. Request
+   prioritization would require some form of caching on the
+   proxy-side. Server push and server hint would require content
+   parsing to identify resources which should be treated
+   specially.
+
+5. Security and policy implications
+
+   A SPDY proxy would be a significant amount of code, and may
+   pull in external libraries. This code will process potentially
+   malicious data, both at the SPDY and HTTP sides. This proposal
+   therefore increases the risk that exit nodes will be
+   compromised by exploiting a bug in the proxy.
+
+   This proposal would also be the first way in which Tor is
+   modifying TCP stream data. Arguably this is still meta-data
+   (HTTP headers), but there may be some concern that Tor should
+   not be doing this.
+
+   Torbutton only works with Firefox, but SPDY only works with
+   Google Chrome. We should be careful not to recommend that
+   users adopt a browser which harms their privacy in other ways.
+
+6. Open questions:
+
+  - How difficult would this be to implement?
+
+  - How much performance improvement would it actually result in?
+
+  - Is there some way to rapidly develop a prototype which would
+    answer the previous question?
+
+[1] SPDY: An experimental protocol for a faster web
+    http://dev.chromium.org/spdy/spdy-whitepaper
+[2] Shining Light in Dark Places: Understanding the Tor Network Damon McCoy,
+    Kevin Bauer, Dirk Grunwald, Tadayoshi Kohno, Douglas Sicker
+    http://www.cs.washington.edu/homes/yoshi/papers/Tor/PETS2008_37.pdf