Opened 7 years ago

Closed 6 years ago

Last modified 5 years ago

#1849 closed project (implemented)

Optimistic Data for Tor

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: iang@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description (last modified by arma)

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

TicketStatusOwnerSummaryComponent
#1795closediangProp 174: Optimistic Data for Tor: Server SideCore Tor/Tor
#1850closednickmProposal 174: Optimistic Data for Tor, relay sideCore Tor/Tor
#3564closedImplement proposal 181 (optimistic data, client side)Core Tor/Tor
#3565closedCache and retry optimistic data on failureCore Tor/Tor
#3617closedMake client-side optimistic data behavior configurableCore Tor/Tor
#3618closedSpecification changes for proposal 181 (client-side optimistic data)Core Tor/Tor

Attachments (1)

optimistic-data.diff (6.0 KB) - added by iang 6 years ago.
Patch for trivsocks-client to support optimistic data

Download all attachments as: .zip

Change History (20)

comment:1 Changed 7 years ago by arma

Description: modified (diff)
Summary: Optimistic Data for TorProject: Optimistic Data for Tor

comment:2 Changed 7 years ago by arma

Description: modified (diff)

comment:3 Changed 7 years ago by arma

Description: modified (diff)

comment:4 Changed 6 years ago by nickm

Milestone: Deliverable-Mar2011Tor: 0.2.3.x-final

comment:5 Changed 6 years ago by nickm

The server side is in 0.2.3.x; now we need to do the client side.

comment:6 Changed 6 years ago by karsten

Summary: Project: Optimistic Data for TorOptimistic Data for Tor
Type: enhancementproject

comment:7 Changed 6 years ago by nickm

Resolution: implemented
Status: newclosed

Woot; I think this is all in now. Closing.

comment:8 Changed 6 years ago by iang

Cc: iang@… added

Are (C) and (D) not part of this ticket?

Changed 6 years ago by iang

Attachment: optimistic-data.diff added

Patch for trivsocks-client to support optimistic data

comment:9 Changed 6 years ago by iang

Here's a patch for (D). It adds a -O option to trivsocks-client in the torperf package to support optimistic data.

comment:10 Changed 6 years ago by nickm

Resolution: implemented
Status: closedreopened

comment:11 Changed 6 years ago by nickm

Well, C and D aren't really in "Tor" precisely, so they should probably get new tickets. I see there's already a ticket for the torperf patch?

As a start on C, how hard would it be to hack up torsocks here?

comment:12 Changed 6 years ago by iang

What'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).

comment:13 in reply to:  12 ; Changed 6 years ago by nickm

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.

comment:14 in reply to:  13 Changed 6 years ago by iang

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.

comment:15 Changed 6 years ago by nickm

readv and writev too.

comment:16 Changed 6 years ago by iang

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?

comment:17 Changed 6 years ago by nickm

Added #3711 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.

comment:18 Changed 6 years ago by nickm

Resolution: implemented
Status: reopenedclosed

I'm going to close this for now, and open a new ticket for application-level support for optimistic data in general. OPtimistic data in tor is done. :)

Thanks again!

comment:19 Changed 5 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.