[tor-bugs] #5707 [Tor]: Use end to end stream timing data to further prune circuits

[Tor Bug Tracker & Wiki]

#5707: Use end to end stream timing data to further prune circuits
------------------------------------------------------------+---------------
 Reporter:  mikeperry                                       |          Owner:  mikeperry         
     Type:  enhancement                                     |         Status:  assigned          
 Priority:  normal                                          |      Milestone:  Tor: 0.2.5.x-final
Component:  Tor                                             |        Version:                    
 Keywords:  SponsorZ performance needs-research tor-client  |         Parent:                    
   Points:                                                  |   Actualpoints:                    
------------------------------------------------------------+---------------

Comment(by mikeperry):

 Replying to [comment:10 arma]:
 > All the researchers doing Tor anonymity analysis get really agitated
 when we add new path selection approaches that aren't based on global
 information. And assuming the congestion is inside the network, where
 you're connecting from shouldn't make a big impact. And finally, all these
 "local not global" approaches raise complex questions about an adversary
 who influences a target user's opinions to influence her paths.
 >
 > So the first question is, how well can we approximate your above plans
 with probers (a la bwauths)? And the followup question is, how much
 information do we need to put into e.g. the consensus for it to work?

 Interpreting your suggestion another way as opposed to a globally-
 constructed timeout: I guess you're suggesting we could alter path
 selection itself based on the measured congestion/queuing information of
 each relay.

 While I admit that this would not have the opportunities for route
 manipulation that a consensus timeout-based approach would, the practical
 problem is that the consensus updates every 2-4 hours for clients.. I
 don't think this is frequent enough for us to measure or model node
 queuing delay.

 I still think we can tune the local system such that it ensures it allows
 within a very close tolerance to the fastest X% of paths. We can also code
 it to disable itself if it is consistently unable to maintain a prediction
 of this timeout such that the expected percentage of stream probes
 actually complete within that timeout. We could also add this code to CBT,
 and have it revert to Tor's 1 minute timeout in such a case..

 > Also, you should know that Micah Sherr's 'virtual coordinate system'
 plan has some code somewhere, though I have so far failed to publically
 pry it out of them.

 I am also having a hard time finding a non-thesis version of this work. Is
 this what you're talking about:
 http://freehaven.net/anonbib/cache/DBLP:conf/pet/SherrBL09.pdf

 However, in general, I don't think a virtual coordinate system will work,
 because I suspect the major issue with Tor for low-latency applications is
 it's own per-hop queuing delay variance, not topology..

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