[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #5707 [Tor Client]: Use end to end timing data to further prune circuits
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs