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

[Tor Bug Tracker & Wiki]

#5707: Use end to end timing data to further prune circuits
-------------------------+--------------------------------------------------
 Reporter:  mikeperry    |          Owner:     
     Type:  enhancement  |         Status:  new
 Priority:  normal       |      Milestone:     
Component:  Tor Client   |        Version:     
 Keywords:  performance  |         Parent:     
   Points:               |   Actualpoints:     
-------------------------+--------------------------------------------------
 At FC12, a "congestion aware" path selection algorithm was proposed.
 http://fc12.ifca.ai/pre-proceedings/paper_46.pdf

 It's broken, and nobody should ever use it. It ends up restricting the
 available paths to an unacceptably low and hard to analyze quantity of the
 network total. Probably something in the ballpark of 20%.

 Instead, we should reuse the CBT code+math with end to end stream timing
 probes (for ex: STREAM CONNECT requests to 127.0.0.1). I will bet my "got
 it by accident along the way" Math degree that the resulting distribution
 is Pareto, which means we can accurately predict to the percentile how
 many paths we would like to reject at this phase using the same code CBT
 uses.

 logder argues that this approach is better than CBT, because CBT primarily
 measure CPU load, not latency, and also the CREATE cell queues are
 different than the RELAY cell queues, which makes circuit building a poor
 performance metric for normal traffic. I don't see a good reason not to do
 both and pick the percentiles such that their product is still
 satisfyingly large. CPU saturated relays should be avoided, anyway, IMO.

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