[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?

 Tor latency has a heavy weight on local characteristics in many instances.

 In fact, the consensus is *exactly* the right place to put a timeout to
 allow a local/censorship adversary to look at the consensus, look at your
 traffic, and delay your circuit by just enough to make it fail when they
 want, so your routes go *where* they want.

 This information needs to be computed locally so we can ensure that your
 Tor client completes a predictable percentage of the total available
 network paths, exactly like the CBT math does.

 In fact, that math actually *works* in the current tor implementation. To
 within +/- 1%, 80% of your circuits build before the circuit build
 timeoutthat your client learns, and you can observe this fact in your logs
 and in the BUILDTIMEOUT_SET values captured by Torperf.

 You keep telling me not to design systems optimized for just one Internet
 connection, and I'm telling you CBT is that system. Please read the spec
 and tell me how to improve it so that this is clear to you:
 https://gitweb.torproject.org/torspec.git/blob/master:/path-spec.txt#l309

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