TBB's Firefox should use optimistic data socks handshake variant
Tor Proposal 181 lets the Tor client save a round-trip if the application speaks socks in a special way. In short, the application needs to send its data before hearing that the socks connection was successful. It's supported as of Tor 0.2.3.3-alpha.
Ian originally had suggested to hack polipo to use a modified socks handshake. With polipo out of the picture for TBB, we should make Firefox itself do it.
Is this something Torbutton should (could) do, or should we patch the Firefox we include in TBB?
Activity
changed milestone to %TorBrowserBundle 2.3.x-stable
We will likely need to patch firefox. Also, my guess is that various disparate pieces of Firefox networking stack are not going to like being told it can send data before getting certain types of error codes. This might be a huge pain in the ass.
Therefore, we should first test a simple hack that has Tor always respond with a connection success to see what the user experience is if SOCKS hangs up in the case of errors rather than mucking around with allowing data to be sent before an error comes back. If the UI doesn't reflect this difference in a way the user is likely to understand in the first place, it seems like there's little point in adding the complexity.
Trac:
Milestone: N/A to TorBrowserBundle 2.3.x-stable
Trac:
Parent: N/A to #3890 (moved)Trac:
Cc: N/A to iang@cs.uwaterloo.ca-
Replying to mikeperry:
We will likely need to patch firefox. Also, my guess is that various disparate pieces of Firefox networking stack are not going to like being told it can send data before getting certain types of error codes. This might be a huge pain in the ass.
Ok. Might be a good argument for sticking an http proxy shim back in. Not that we want to maintain one or have it take up space in the bundle.
Therefore, we should first test a simple hack that has Tor always respond with a connection success to see what the user experience is if SOCKS hangs up in the case of errors rather than mucking around with allowing data to be sent before an error comes back. If the UI doesn't reflect this difference in a way the user is likely to understand in the first place, it seems like there's little point in adding the complexity.
I don't understand this last part. The expected gain is not in UI responsiveness. It's in actually getting the pages faster.
I wonder if a patch to polipo would be simpler, and a good way to test out how much of a difference the optimistic data feature makes.
Trac:
Keywords: N/A deleted, performance roundtrip added -
Replying to arma:
Therefore, we should first test a simple hack that has Tor always respond with a connection success to see what the user experience is if SOCKS hangs up in the case of errors rather than mucking around with allowing data to be sent before an error comes back. If the UI doesn't reflect this difference in a way the user is likely to understand in the first place, it seems like there's little point in adding the complexity.
I don't understand this last part. The expected gain is not in UI responsiveness. It's in actually getting the pages faster.
What I meant was instead of creating a shim or changing anything on the Firefox side, let's just test what happens with Tor Browser as it is today if the Tor SOCKS handshake always responds with success to connection attempts, only to close later if the data doesn't actually make it.
This test requires no change to Firefox to carry out.
If the user experience is not substantially different from what it is without the SOCKS change on the Tor side, there is no reason to devote any additional development effort either to change Firefox, or to introduce a shim. We can just deploy the feature immediately.
If there are differences in the user experience, we can perhaps just correct those to make them more uniform. In fact, the error messages Firefox currently gives on connection failure are already pretty uniform, regardless of the type of failure.
Is optimistic data already on by default for Tor 0.2.3.x? If I point my TBB at a 0.2.3.x tor client, can I try this test today?
I wonder if a patch to polipo would be simpler, and a good way to test out how much of a difference the optimistic data feature makes.
While I have a penchant for distrusting academic results, I see no reason to doubt Ian's own data in this case. It seems obvious to me there will be significant improvement in load time by eliminating the round trip for connection setup.
In fact, I was actually a little embarrassed I didn't think of it myself, having worked at a company pretty much exclusively devoted to removing round trips from braindead protocols.
-
Replying to mikeperry:
What I meant was instead of creating a shim or changing anything on the Firefox side, let's just test what happens with Tor Browser as it is today if the Tor SOCKS handshake always responds with success to connection attempts, only to close later if the data doesn't actually make it.
This test requires no change to Firefox to carry out.
Oh! So a Tor client patch you mean. I opened #5915 (moved) with what I think you meant.
-
Replying to mikeperry:
Is optimistic data already on by default for Tor 0.2.3.x? If I point my TBB at a 0.2.3.x tor client, can I try this test today?
You'll need to set "OptimisticData 1" in your torrc. And I don't know how much it's been tested. But it is supposed to be working, yes.
-
Replying to iang:
Tao's actually working on this as we speak. He's trying both the "tiny change to FF" and the "just modify the OP" approaches. If either of you will be at Oakland, he'll be here too.
Ian:
I forgot to bring this up with him at Oakland.
Any news?
Replying to arma:
Replying to iang:
Tao's actually working on this as we speak. He's trying both the "tiny change to FF" and the "just modify the OP" approaches. If either of you will be at Oakland, he'll be here too.
Ian:
I forgot to bring this up with him at Oakland.
Any news?
I've implemented preliminary versions of both. Right now, the "tiny change to FF" approach works except for the SSL handshake, which is to say it does not work. The "modifying OP" approach works, but doesn't deal with some errors very well yet. I will keep you updated when either or both approaches do in fact work.
Trac:
Username: t55wang-
Replying to t55wang:
I've implemented preliminary versions of both. Right now, the "tiny change to FF" approach works except for the SSL handshake, which is to say it does not work. The "modifying OP" approach works, but doesn't deal with some errors very well yet. I will keep you updated when either or both approaches do in fact work.
How exactly does the SSL handshake fail, and in what cases?
And for the OP case, what does "not dealing with some errors very well" mean in practice? The user experience for errors is already pretty bad. I think in practice we can ignore most UX issues with the errors since the perf benefit for the good case is so clear.
Also, can you attach patches as well? It will make it easier for us to make suggestions/decisions.
-
Trac:
Username: t55wang -
Trac:
Username: t55wang -
Replying to mikeperry:
Replying to t55wang:
I've implemented preliminary versions of both. Right now, the "tiny change to FF" approach works except for the SSL handshake, which is to say it does not work. The "modifying OP" approach works, but doesn't deal with some errors very well yet. I will keep you updated when either or both approaches do in fact work.
How exactly does the SSL handshake fail, and in what cases?
And for the OP case, what does "not dealing with some errors very well" mean in practice? The user experience for errors is already pretty bad. I think in practice we can ignore most UX issues with the errors since the perf benefit for the good case is so clear.
These things have been fixed. For the SSL handshake, I told it to stop polling after one round and I shouldn't have. For the errors, I meant that DNS resolution failure returns "connection has been reset" to the Browser, which seems confusing, so I wrote an error message explaining what happened (copying from the original "Tor is not an HTTP proxy" message) for that case.
Also, can you attach patches as well? It will make it easier for us to make suggestions/decisions.
I have included patches for both the Tor Browser and Tor. Both are working, but performance measurements are underway and should be done by tomorrow.
The Tor Browser fix is slightly more involved, as it introduces a new state to the connect process (marking where the GET request can be sent) and changes the behavior of the SOCKS handshake. I am not sure if there are unforeseen consequences of flipping the handshake on its head - everything I've tried has worked so far. The Tor fix is much simpler (the core is literally one line), but there are some potential problems. We did a "hack" where Tor checks if the port we're trying to talk to is port 80, and only displays the specific HTTP error message (for DNS resolution failure) in that situation. There's also the problem that Tor is essentially lying to Firefox by telling it that the socks connect has been accepted by the end server, when it hasn't been.
Trac:
Username: t55wang -
Trac:
Username: t55wang
Cc: iang@cs.uwaterloo.ca to iang@cs.uwaterloo.ca, t55wang@uwaterloo.ca