[tor-bugs] #1849 [Tor Client]: Project: Optimistic Data for Tor

[Tor Bug Tracker & Wiki]

#1849: Project: Optimistic Data for Tor
-------------------------+--------------------------------------------------
 Reporter:  arma         |       Owner:                     
     Type:  enhancement  |      Status:  new                
 Priority:  normal       |   Milestone:  Deliverable-Mar2011
Component:  Tor Client   |     Version:                     
 Keywords:               |      Parent:                     
-------------------------+--------------------------------------------------
Description changed by arma:

Old 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.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)]]

New 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.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.

--

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1849#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online