[tor-bugs] #28025 [Core Tor/Torflow]: unintended consequence of geographically distributed bandwidth servers: higher vote instability

Tor Bug Tracker & Wiki blackhole at torproject.org
Fri Oct 12 21:03:55 UTC 2018


#28025: unintended consequence of geographically distributed bandwidth servers:
higher vote instability
-----------------------+----------------------------------
 Reporter:  starlight  |          Owner:  tom
     Type:  defect     |         Status:  new
 Priority:  Medium     |      Component:  Core Tor/Torflow
  Version:             |       Severity:  Normal
 Keywords:             |  Actual Points:
Parent ID:             |         Points:
 Reviewer:             |        Sponsor:
-----------------------+----------------------------------
 The manner in which ticket #24674 was implemented has caused Torflow
 voting to become increasing unstable.

 IIUC Torflow switches from one configured bandwidth server to the next in
 succession, but does not maintain separate sets of measurement data for
 each server.  Thus if a scan is performed against a server in fast region
 such as central Europe and next in a slow region such as South America,
 new slow measurements are compared against the fast average bandwidth
 established in the preceding cycle, and vice-versa.

 The moria1 scanner appears to recently have commenced operating with
 multiple servers configured while the maatuska scanner remains configured
 with one server.  A recent synchronous pair of scan results from the two
 illustrates this problem and is attached.  Moria1 results show much higher
 variance in pid_delta values than maatuska results:  sorted by slice from
 highest down

 moria1 pid_delta variances:

 scanner1:  2.35 2.32 1.01 1.32 0.65 0.79 0.76 0.51 1.12 0.43
 scanner2:  0.97 0.94

 maatuska pid_delta variances:

 scanner1:  0.31 0.42 0.41 0.41 0.26 0.27 0.38 0.49 0.28 0.36 0.34
 scanner2:  0.42 0.36 0.46

 At a minimum SBWS should address this issue by segregating measurment data
 by scanner.

 For the present my opinion is that Torflow configurations should be
 reverted to one-server-per scanner to reduce vote instability and restore
 it to what it was before ticket #24674 was implemented.

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


More information about the tor-bugs mailing list