[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):

 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