[tor-bugs] #8240 [Tor]: Raise our guard rotation period

[Tor Bug Tracker & Wiki]

#8240: Raise our guard rotation period
----------------------------------------------------+-----------------------
 Reporter:  arma                                    |          Owner:                    
     Type:  defect                                  |         Status:  needs_revision    
 Priority:  major                                   |      Milestone:  Tor: 0.2.4.x-final
Component:  Tor                                     |        Version:                    
 Keywords:  tor-client needs-proposal 023-backport  |         Parent:                    
   Points:                                          |   Actualpoints:                    
----------------------------------------------------+-----------------------

Comment(by mikeperry):

 For the branch for 0.2.4.x: I agree we should default to 2 or 3 months
 instead of 9 months here. I also took a quick look at the branch and it
 seems weird to clamp the torrc option silently. If we're going to alter
 user torrc values, it should probably be in options_validate() with a log
 message. I also think 2 months is a high minimum, especially for torrc.
 Seems like "10 minutes" is a better minimum there. The consensus I agree
 we might want to bottom out at a month.

 For 0.2.5.x when we actually change this to a larger value: I thought
 about the weight discussion a bit more. It of course needs a proposal to
 make it specific enough to implement, but I think the best option would be
 to create a new consensus method that allows each relay to optionally have
 a subset of the bandwidth-weights keyword pairs (the Wxx ones used by
 compute_weighted_bandwidths() and
 smartlist_choose_node_by_bandwidth_weights()) on its 'w' line, which would
 override the values from the consensus footer if present.

 We would then compute these W*g* weights for each relay at the authorities
 depending on how old of a guard a relay is using a scaling function
 similar to what arma/I mentioned earlier (probably a simple linear
 function that represents a constant rate of client arrival and migration
 until we hit an age greater than the rotation period).

 We'd also probably want to alter the bandwidth-weight computation at the
 end to multiply these overrides by the relay bandwidth, as if that
 multiplied value were the total bandwidth for that relay for that flag.
 This would give us more realistic fractions of how much bandwidth actually
 is being actively used for the Guard vs other positions during any given
 consensus period.

 Once those two changes are made, we should be free to make this value as
 large as we want without impacting balancing significantly, I think. We
 should also be able to observe in practice that getting the Guard flag
 should no longer cause your relay to suddenly drop in traffic volume, so
 it will hopefully be obvious if its actually working.

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