task-2911/README

   1 Tech report: An Analysis of Tor Relay Stability
   2 ===============================================
   3
   4 We developed a simulator for the tech report "An Analysis of Tor Relay
   5 Stability" that varies the requirements for assigning Stable and Guard
   6 flags to relays and evaluates how useful these assignments are.  In this
   7 README we describe how to use the simulator to re-run and possibly modify
   8 our analysis.
   9
  10 First, download the comma-separated value file containing extracted status
  11 entries and server descriptors parts from the metrics database.  The file
  12 is called running-relays-reverse.csv and contains lines like the
  13 following:
  14
  15   2011-06-30 23:00:00,0089102aa16208d991dc36efafd5cf13b35aa707,
  16       f,f,f,193581,1148763136
  17
  18 The columns are:
  19
  20  - consensus valid-after time
  21  - relay fingerprint
  22  - whether the relay was restarted in the last hour (t/f)
  23  - whether the relay got the Stable flag assigned (t/f)
  24  - whether the relay got the Guard flag assigned (t/f)
  25  - advertised bandwidth in bytes per day
  26  - written bytes per day
  27
  28 If you don't have this file or want to generate your own file, you can
  29 export status entries and server descriptor parts from the metrics
  30 database.  Be sure to plan for a buffer of at least 4 months (better: 6
  31 months) before and after the interval to investigate.  The psql commands
  32 and SELECT statement for extracting these data are as follows:
  33
  34   tordir=> \f ','
  35   tordir=> \a
  36   tordir=> \t
  37   tordir=> \o running-relays-reverse.csv
  38   tordir=> SELECT statusentry.validafter,
  39              statusentry.fingerprint,
  40              CASE WHEN descriptor.uptime IS NULL THEN FALSE ELSE
  41                statusentry.validafter - descriptor.published +
  42                descriptor.uptime * '1 second'::INTERVAL <
  43                  '01:00:00'::INTERVAL END AS restarted,
  44              statusentry.isstable,
  45              statusentry.isguard,
  46              LEAST(descriptor.bandwidthavg, descriptor.bandwidthobserved)
  47                AS bwadvertised,
  48              bwhist.written_sum AS writtensum
  49            FROM statusentry
  50            LEFT JOIN descriptor
  51            ON statusentry.descriptor = descriptor.descriptor
  52            LEFT JOIN bwhist
  53            ON DATE(statusentry.validafter) = bwhist.date
  54            AND statusentry.fingerprint = bwhist.fingerprint
  55            WHERE statusentry.isrunning
  56            AND statusentry.validafter >= '2010-01-01 00:00:00'
  57            AND statusentry.validafter < '2011-07-01 00:00:00'
  58            ORDER BY statusentry.validafter DESC, statusentry.fingerprint;
  59   tordir=> \o
  60   tordir=> \q
  61
  62 The simulator needs to parse the file in forward and in reverse direction.
  63 The easiest way to implement this is to reverse the file using tac:
  64
  65   $ tac running-relays-reverse.csv > running-relays-foward.csv
  66
  67 Run the simulation consisting of a reverse and a forward run.  The results
  68 of the reverse run will be stored to the future-stability/ directory and
  69 will be re-used in subsequent simulations.  Delete or move away the
  70 future-stability/ directory to repeat the reverse run, too.  The execution
  71 can take 20--30 minutes or even more depending on your hardware.
  72
  73   $ javac SimulateStableGuard.java
  74   $ java SimulateStableGuard
  75
  76 The result is a file stability.csv that contains the following columns:
  77
  78 - time: consensus valid-after time
  79 - excladvbw, exclwfu, exclwt: the number of relays that did not get the
  80   Guard flag assigned in the simulation which got it from the directory
  81   authorities; excladvbw did not get it because of the advertised
  82   bandwidth requirement, exclwfu because of the WFU requirement, and
  83   exclwt because of the weighted time requirement; it's quite possible
  84   that a relay did not get the Guard flag for more than one reason
  85 - familiar: absolute number of `familiar' relays
  86 - guard: absolute number of relays with the Guard flag as assigned by the
  87   directory authorities
  88 - guardYYwfuZZadvbw: absolute number of relays with the Guard flag as
  89   assigned in the simulation when using YY as the WFU percentile and ZZ as
  90   the advertised bandwidth percentile
  91 - guardintersect, guardobserved, guardsimulated: number of relays that got
  92   the Guard flag both by the directory authorities and by the simulator or
  93   that only got it by one of them
  94 - minadvbwaZZadvbw: Minimum advertised bandwidth when using ZZ as the
  95   advertised bandwidth percentile, before cutting it down to 250 KiB/s
  96 - minadvbwbZZadvbw: Minimum advertised bandwidth when using ZZ as the
  97   advertised bandwidth percentile, after cutting it down to 250 KiB/s
  98 - minwfuaYYwfu: Minimum WFU when using YY as the WFU percentile, before
  99   cutting it down to 0.98
 100 - minwfubYYwfu: Minimum WFU when using YY as the WFU percentile, after
 101   cutting it down to 0.98
 102 - minwmtbfaXX: Minimum WMTBF when using XX as the WMTBF percentile, before
 103   cutting it down to 5 days
 104 - minwmtbfbXX: Minimum WMTBF when using XX as the WMTBF percentile, after
 105   cutting it down to 5 days
 106 - minwta: Minimum weighted time before cutting it down to 8 days
 107 - minwtb: Minimum weighted time after cutting it down to 8 days
 108 - mtunfXX: Mean time until next failure when using XX as the WMTBF
 109   percentile
 110 - mwfu: Mean WFU of relays that got the Guard flag assigned by the
 111   directory authorities
 112 - mwfuYYwfuZZadvbw: Mean WFU when using YY as the WFU percentile and ZZ as
 113   the advertised bandwidth percentile
 114 - percWWfwb: WW-th percentile of future weighted bandwidth of relays that
 115   got the Guard flag assigned by the directory authorities
 116 - percWWfwbYYwfuZZadvbw: WW-th percentile of future weighted bandwidth
 117   when using YY as the WFU percentile and ZZ as the advertised bandwidth
 118   percentile
 119 - percWWtunf: WW-th percentile of time until next failure of relays that
 120   got the Stable flag assigned by the directory authorities
 121 - percWWtunfXX: WW-th percentile of time until next failure when using XX
 122   as the WMTBF percentile
 123 - percWWwfu: WW-th percentile of WFU of relays that got the Guard flag
 124   assigned by the directory authorities
 125 - percWWwfuYYwfuZZadvbw: WW-th percentile of WFU when using YY as the WFU
 126   percentile and ZZ as the advertised bandwidth percentile
 127 - running: absolute number of running relays
 128 - stable: absolute number of relays with the Stable flag as assigned by the
 129   directory authorities
 130 - stableXX: absolute number of relays with the Stable flag as assigned in
 131   the simulation when using XX as WMTBF percentile
 132 - stableintersect, stableobserved, stablesimulated: number of relays that
 133   got the Stable flag both by the directory authorities and by the
 134   simulator or that only got it by one of them
 135
 136 Plot the graphs for the tech report:
 137
 138   $ R --slave -f stability.R
 139
 140 The report sources are in tech-reports.git/2011/relay-stability/.
 141