[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #8240 [Tor]: Raise our guard rotation period
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs