[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-commits] [torspec/master] Add proposal 181 (Optimistic data, client side) from Ian Goldberg
commit 2ab6738fa3695773b537d09e59575bc3d9be27cf
Author: Nick Mathewson <nickm@xxxxxxxxxxxxxx>
Date: Sat Jun 4 23:08:40 2011 -0400
Add proposal 181 (Optimistic data, client side) from Ian Goldberg
---
proposals/000-index.txt | 2 +
proposals/181-optimistic-data-client.txt | 127 ++++++++++++++++++++++++++++++
2 files changed, 129 insertions(+), 0 deletions(-)
diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index dca67dc..06e97b5 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -101,6 +101,7 @@ Proposals by number:
178 Require majority of authorities to vote for consensus parameters [OPEN]
179 TLS certificate and parameter normalization [DRAFT]
180 Pluggable transports for circumvention [OPEN]
+181 Optimistic Data for Tor: Client Side [OPEN]
Proposals by status:
@@ -130,6 +131,7 @@ Proposals by status:
177 Abstaining from votes on individual flags [for 0.2.3.x]
178 Require majority of authorities to vote for consensus parameters [for 0.2.3.x]
180 Pluggable transports for circumvention [for 0.2.3.x]
+ 181 Optimistic Data for Tor: Client Side
ACCEPTED:
110 Avoiding infinite length circuits [for 0.2.3.x] [in 0.2.1.3-alpha]
117 IPv6 exits [for 0.2.3.x]
diff --git a/proposals/181-optimistic-data-client.txt b/proposals/181-optimistic-data-client.txt
new file mode 100644
index 0000000..733b8a1
--- /dev/null
+++ b/proposals/181-optimistic-data-client.txt
@@ -0,0 +1,127 @@
+Filename: 181-optimistic-data-client.txt
+Title: Optimistic Data for Tor: Client Side
+Author: Ian Goldberg
+Created: 2-Jun-2011
+Status: Open
+
+Overview:
+
+This proposal (as well as its already-implemented sibling concerning the
+server side) aims to reduce the latency of HTTP requests in particular
+by allowing:
+1. SOCKS clients to optimistically send data before they are notified
+ that the SOCKS connection has completed successfully
+2. OPs to optimistically send DATA cells on streams in the CONNECT_WAIT
+ state
+3. Exit nodes to accept and queue DATA cells while in the
+ EXIT_CONN_STATE_CONNECTING state
+
+This particular proposal deals with #1 and #2.
+
+For more details (in general and for #3), see the sibling proposal 174
+(Optimistic Data for Tor: Server Side), which has been implemented in
+0.2.3.1-alpha.
+
+Motivation:
+
+This change will save one OP<->Exit round trip (down to one from two).
+There are still two SOCKS Client<->OP round trips (negligible time) and
+two Exit<->Server round trips. Depending on the ratio of the
+Exit<->Server (Internet) RTT to the OP<->Exit (Tor) RTT, this will
+decrease the latency by 25 to 50 percent. Experiments validate these
+predictions. [Goldberg, PETS 2010 rump session; see
+https://thunk.cs.uwaterloo.ca/optimistic-data-pets2010-rump.pdf ]
+
+Design:
+
+Currently, data arriving on the SOCKS connection to the OP on a stream
+in AP_CONN_STATE_CONNECT_WAIT is queued, and transmitted when the state
+transitions to AP_CONN_STATE_OPEN. Instead, when data arrives on the
+SOCKS connection to the OP on a stream in AP_CONN_STATE_CONNECT_WAIT
+(connection_edge_process_inbuf):
+
+- Check to see whether optimistic data is allowed at all (see below).
+- Check to see whether the exit node for this stream supports optimistic
+ data (according to tor-spec.txt section 6.2, this means that the
+ exit node's version number is at least 0.2.3.1-alpha). If you don't
+ know the exit node's version number (because it's not in your
+ hashtable of fingerprints, for example), assume it does *not* support
+ optimistic data.
+- If both are true, transmit the data on the stream.
+
+Also, when a stream transitions *to* AP_CONN_STATE_CONNECT_WAIT
+(connection_ap_handshake_send_begin), do the above checks, and
+immediately send any already-queued data if they pass.
+
+SOCKS clients (e.g. polipo) will also need to be patched to take
+advantage of optimistic data. The simplest solution would seem to be to
+just start sending data immediately after sending the SOCKS CONNECT
+command, without waiting for the SOCKS server reply. When the SOCKS
+client starts reading data back from the SOCKS server, it will first
+receive the SOCKS server reply, which may indicate success or failure.
+If success, it just continues reading the stream as normal. If failure,
+it does whatever it used to do when a SOCKS connection failed.
+
+Security implications:
+
+ORs (for sure the Exit, and possibly others, by watching the
+pattern of packets), as well as possibly end servers, will be able to
+tell that a particular client is using optimistic data. This of course
+has the potential to fingerprint clients, dividing the anonymity set.
+The usual kind of solution is suggested:
+
+- There is a boolean consensus parameter UseOptimisticData.
+- There is a 3-state (-1, 0, 1) configuration parameter
+ UseOptimisticData (or give it a distinct name if you like)
+ defaulting to -1.
+- If the configuration parameter is -1, the OP obeys the consensus
+ value; otherwise, it obeys the configuration parameter.
+
+It may be wise to set the consensus parameter to 1 at the same time as
+similar other client protocol changes are made (for example, a new
+circuit construction protocol) in order to not further subdivide the
+anonymity set.
+
+Specification:
+
+The current tor-spec has already been updated by proposal 174 to handle
+optimistic data. It says, in part:
+
+ If the exit node does not support optimistic data (i.e. its version
+ number is before 0.2.3.1-alpha), then the OP MUST wait for a
+ RELAY_CONNECTED cell before sending any data. If the exit node
+ supports optimistic data (i.e. its version number is 0.2.3.1-alpha
+ or later), then the OP MAY send RELAY_DATA cells immediately after
+ sending the RELAY_BEGIN cell (and before receiving either a
+ RELAY_CONNECTED or RELAY_END cell).
+
+Should the "MAY" be more specific, referring to the consensus
+parameters? Or does the existence of the configuration parameter
+override mean it's really "MAY", regardless?
+
+Compatibility:
+
+There are compatibility issues, as mentioned above. OPs MUST NOT send
+optimistic data to Exit nodes whose version numbers predate
+0.2.3.1-alpha. OPs MAY send optimistic data to Exit nodes whose version
+numbers match or follow that value.
+
+Implementation:
+
+My git diff is 42 lines long (+17 lines, -1 line), changing only the two
+functions mentioned above (connection_edge_process_inbuf and
+connection_ap_handshake_send_begin). This diff does not, however,
+handle the configuration options, or check the version number of the
+exit node.
+
+I have patched a command-line SOCKS client (webfetch) to use optimistic
+data. I have not attempted to patch polipo, but I have looked at it a
+bit, and it seems pretty straightforward. (Of course, if and when
+polipo is deprecated, whatever else speaks SOCKS to the OP should take
+advantage of optimistic data.)
+
+Performance and scalability notes:
+
+OPs may queue a little more data, if the SOCKS client pushes it faster
+than the OP can write it out. But that's also true today after the
+SOCKS CONNECT returns success, right?
_______________________________________________
tor-commits mailing list
tor-commits@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits