Optimistic Data for Tor
Ian has a design in mind where Tor clients can send the HTTP GET part of their request right after the RELAY BEGIN request, to save a round-trip during web browsing. That sounds like a great idea. https://thunk.cs.uwaterloo.ca/optimistic-data-pets2010-rump.pdf
As I understand it, there are three components that need doing:
A) Tor exit relays need to be able to queue up data cells that arrive right after begin cells, and then process them once the exit stream is established.
B) Tor clients need to learn a new version of socks, or some other way to recognize when the application is trying to play the optimistic game. Then they need to send the data cells after the begin cells, but still remember them if they decide later to move to a different circuit (e.g. if their begin cell times out or fails).
C) The application side of things needs to learn to signal that it wants optimistic data. Maybe we can modify polipo or shim to do this. Or maybe we can find a way to not need this piece, since it would be a shame to add a new http proxy dependency when we're trying to cut the http proxy out of the loop.
D) Set up a Torperf variant that uses optimistic data, and compare performance results for various web browsing patterns.
Activity
changed milestone to %Tor: 0.2.3.x-final
Trac:
Summary: Optimistic Data for Tor to Project: Optimistic Data for Tor
Description: Ian has a design in mind where Tor clients can send the HTTP GET part of their request right after the RELAY BEGIN request, to save a round-trip during web browsing. That sounds like a great idea. https://thunk.cs.uwaterloo.ca/optimistic-data-pets2010-rump.pdfAs I understand it, there are three components that need doing:
A) Tor exit relays need to be able to queue up data cells that arrive right after begin cells, and then process them once the exit stream is established.
B) Tor clients need to learn a new version of socks, or some other way to recognize when the application is trying to play the optimistic game. Then they need to send the data cells after the begin cells, but still remember them if they decide later to move to a different circuit (e.g. if their begin cell times out or fails).
C) The application side of things needs to learn to signal that it wants optimistic data. Maybe we can modify polipo or shim to do this. Or maybe we can find a way to not need this piece, since it would be a shame to add a new http proxy dependency when we're trying to cut the http proxy out of the loop.
to
Ian has a design in mind where Tor clients can send the HTTP GET part of their request right after the RELAY BEGIN request, to save a round-trip during web browsing. That sounds like a great idea. https://thunk.cs.uwaterloo.ca/optimistic-data-pets2010-rump.pdf
As I understand it, there are three components that need doing:
A) Tor exit relays need to be able to queue up data cells that arrive right after begin cells, and then process them once the exit stream is established.
B) Tor clients need to learn a new version of socks, or some other way to recognize when the application is trying to play the optimistic game. Then they need to send the data cells after the begin cells, but still remember them if they decide later to move to a different circuit (e.g. if their begin cell times out or fails).
C) The application side of things needs to learn to signal that it wants optimistic data. Maybe we can modify polipo or shim to do this. Or maybe we can find a way to not need this piece, since it would be a shame to add a new http proxy dependency when we're trying to cut the http proxy out of the loop.
Child Tickets: [[TicketQuery(parent=#1849 (moved))]]
-
Trac:
Description: Ian has a design in mind where Tor clients can send the HTTP GET part of their request right after the RELAY BEGIN request, to save a round-trip during web browsing. That sounds like a great idea. https://thunk.cs.uwaterloo.ca/optimistic-data-pets2010-rump.pdfAs I understand it, there are three components that need doing:
A) Tor exit relays need to be able to queue up data cells that arrive right after begin cells, and then process them once the exit stream is established.
B) Tor clients need to learn a new version of socks, or some other way to recognize when the application is trying to play the optimistic game. Then they need to send the data cells after the begin cells, but still remember them if they decide later to move to a different circuit (e.g. if their begin cell times out or fails).
C) The application side of things needs to learn to signal that it wants optimistic data. Maybe we can modify polipo or shim to do this. Or maybe we can find a way to not need this piece, since it would be a shame to add a new http proxy dependency when we're trying to cut the http proxy out of the loop.
Child Tickets: [[TicketQuery(parent=#1849 (moved))]]
to
Ian has a design in mind where Tor clients can send the HTTP GET part of their request right after the RELAY BEGIN request, to save a round-trip during web browsing. That sounds like a great idea. https://thunk.cs.uwaterloo.ca/optimistic-data-pets2010-rump.pdf
As I understand it, there are three components that need doing:
A) Tor exit relays need to be able to queue up data cells that arrive right after begin cells, and then process them once the exit stream is established.
B) Tor clients need to learn a new version of socks, or some other way to recognize when the application is trying to play the optimistic game. Then they need to send the data cells after the begin cells, but still remember them if they decide later to move to a different circuit (e.g. if their begin cell times out or fails).
C) The application side of things needs to learn to signal that it wants optimistic data. Maybe we can modify polipo or shim to do this. Or maybe we can find a way to not need this piece, since it would be a shame to add a new http proxy dependency when we're trying to cut the http proxy out of the loop.
D) Set up a Torperf variant that uses optimistic data, and compare performance results for various web browsing patterns.
Child Tickets: [[TicketQuery(parent=#1849 (moved))]]
-
Trac:
Description: Ian has a design in mind where Tor clients can send the HTTP GET part of their request right after the RELAY BEGIN request, to save a round-trip during web browsing. That sounds like a great idea. https://thunk.cs.uwaterloo.ca/optimistic-data-pets2010-rump.pdfAs I understand it, there are three components that need doing:
A) Tor exit relays need to be able to queue up data cells that arrive right after begin cells, and then process them once the exit stream is established.
B) Tor clients need to learn a new version of socks, or some other way to recognize when the application is trying to play the optimistic game. Then they need to send the data cells after the begin cells, but still remember them if they decide later to move to a different circuit (e.g. if their begin cell times out or fails).
C) The application side of things needs to learn to signal that it wants optimistic data. Maybe we can modify polipo or shim to do this. Or maybe we can find a way to not need this piece, since it would be a shame to add a new http proxy dependency when we're trying to cut the http proxy out of the loop.
D) Set up a Torperf variant that uses optimistic data, and compare performance results for various web browsing patterns.
Child Tickets: [[TicketQuery(parent=#1849 (moved))]]
to
Ian has a design in mind where Tor clients can send the HTTP GET part of their request right after the RELAY BEGIN request, to save a round-trip during web browsing. That sounds like a great idea. https://thunk.cs.uwaterloo.ca/optimistic-data-pets2010-rump.pdf
As I understand it, there are three components that need doing:
A) Tor exit relays need to be able to queue up data cells that arrive right after begin cells, and then process them once the exit stream is established.
B) Tor clients need to learn a new version of socks, or some other way to recognize when the application is trying to play the optimistic game. Then they need to send the data cells after the begin cells, but still remember them if they decide later to move to a different circuit (e.g. if their begin cell times out or fails).
C) The application side of things needs to learn to signal that it wants optimistic data. Maybe we can modify polipo or shim to do this. Or maybe we can find a way to not need this piece, since it would be a shame to add a new http proxy dependency when we're trying to cut the http proxy out of the loop.
D) Set up a Torperf variant that uses optimistic data, and compare performance results for various web browsing patterns.
Are (C) and (D) not part of this ticket?
Trac:
Cc: N/A to iang@cs.uwaterloo.caTrac:
optimistic-data.diffWhat's the number of the torperf ticket?
As for torsocks, the question is what do you do if the OP ends up returning an error? torsocks must have already told the SOCKS client that the connect() succeeded, so it could, what, just cause subsequent read() and write() calls to the socket to return -1 and set errno to something plausible? Hopefully the SOCKS client would notice that, close the socket, and report an error (though probably not the right one).
Replying to iang:
What's the number of the torperf ticket?
Maybe not; I thought I'd seen you open one. :/
As for torsocks, the question is what do you do if the OP ends up returning an error? torsocks must have already told the SOCKS client that the connect() succeeded, so it could, what, just cause subsequent read() and write() calls to the socket to return -1 and set errno to something plausible? Hopefully the SOCKS client would notice that, close the socket, and report an error (though probably not the right one).
I think that's about right; ECONNRESET seems like a good error here. We'd probably want to have a way to disable this too.
Replying to nickm:
I think that's about right; ECONNRESET seems like a good error here. We'd probably want to have a way to disable this too.
So the only trick is that torsocks doesn't currently capture write/read/send/recv/sendto/recvfrom at all, which it would need to do. (Did I miss any there? Ugh.) Other than that, it looks pretty straightforward.
Another wrinkle: you have to wrap select/poll and friends so that if they're about to return that an fd is available for reading, but the SOCKS reply for that fd hasn't been read yet, the wrapper reads the SOCKS reply and does not report that it's ready (which may necessitate calling select() again to wait for more data).
This discussion should really be in another ticket. Where should it go?
-
Added #3711 (moved) to talk about torsocks. Please add any more tickets you think we need: I don't think I get all the other issues with them well enough to write up what we ought to do.
Trac:
Reviewer: N/A to N/A
Sponsor: N/A to N/A
Description: Ian has a design in mind where Tor clients can send the HTTP GET part of their request right after the RELAY BEGIN request, to save a round-trip during web browsing. That sounds like a great idea. https://thunk.cs.uwaterloo.ca/optimistic-data-pets2010-rump.pdfAs I understand it, there are three components that need doing:
A) Tor exit relays need to be able to queue up data cells that arrive right after begin cells, and then process them once the exit stream is established.
B) Tor clients need to learn a new version of socks, or some other way to recognize when the application is trying to play the optimistic game. Then they need to send the data cells after the begin cells, but still remember them if they decide later to move to a different circuit (e.g. if their begin cell times out or fails).
C) The application side of things needs to learn to signal that it wants optimistic data. Maybe we can modify polipo or shim to do this. Or maybe we can find a way to not need this piece, since it would be a shame to add a new http proxy dependency when we're trying to cut the http proxy out of the loop.
D) Set up a Torperf variant that uses optimistic data, and compare performance results for various web browsing patterns.
to
Ian has a design in mind where Tor clients can send the HTTP GET part of their request right after the RELAY BEGIN request, to save a round-trip during web browsing. That sounds like a great idea. https://thunk.cs.uwaterloo.ca/optimistic-data-pets2010-rump.pdf
As I understand it, there are three components that need doing:
A) Tor exit relays need to be able to queue up data cells that arrive right after begin cells, and then process them once the exit stream is established.
B) Tor clients need to learn a new version of socks, or some other way to recognize when the application is trying to play the optimistic game. Then they need to send the data cells after the begin cells, but still remember them if they decide later to move to a different circuit (e.g. if their begin cell times out or fails).
C) The application side of things needs to learn to signal that it wants optimistic data. Maybe we can modify polipo or shim to do this. Or maybe we can find a way to not need this piece, since it would be a shame to add a new http proxy dependency when we're trying to cut the http proxy out of the loop.
D) Set up a Torperf variant that uses optimistic data, and compare performance results for various web browsing patterns.
mentioned in issue #1850 (moved)
mentioned in issue #1853 (closed)
mentioned in issue #3618 (moved)
mentioned in issue #3711 (moved)
moved to tpo/core/tor#1849 (closed)
mentioned in issue tpo/core/tor#1850 (closed)
mentioned in issue tpo/core/torsocks#3711
