[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #5707 [Tor]: Use end to end stream timing data to further prune circuits
#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):
I've been brainstorming about how to best deploy something like this. I
have the following high-level ideas about how we'd use it to best effect:
1. We create a LowLatencyPorts torrc option to include ports where
interactive latency matters more than connection setup time. This would
include such things as SSH, Skype, Mumble, jitsi, etc.
2. We set two pairs of consensus parameters: one for these sets of ports,
and another for predictive-built circuits. Each pair would have a CBT part
and and a Stream Ping Timeout part (SPT).
3. If a stream request (or predictive build) comes in for a LowLatencyPort
and we don't have any such circuits available, we apply the CBT value for
the construction, and then run the ping and apply that. We then flag any
such circuits that survive the CBT timeout and the SPT timeout as
acceptable for use for such ports.
4. For normal predictive circuits, we would apply CBT + SPT, but with
higher (more lenient) values. For all other on-demand circuits, we'd apply
CBT only (so you don't have to wait for a end-to-end ping before using
them).
I'm thinking that the cutoffs would be something like CBT=85 SPT=85 for
predictive circuits (yielding the "fastest" 72% of network paths for
them), CBT=80 SPT=50 for LowLatencyPort circuits (yielding the "fastest"
40% of paths for them), and CBT=75 for all other on-demand circuits.
Of course, we'll want to tune LowLatency SPT cutoffs such that they can
actually support voice traffic.
I think this hack alone will get us to the SponsorF deliverable for voice.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5707#comment:9>
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