mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-30 23:53:32 +01:00
d230827912
Tor doesn't use SVN anymore, making $Revision$, $Id$ and $Date$ meaningless. Remove them without replacement.
79 lines
3.3 KiB
Plaintext
79 lines
3.3 KiB
Plaintext
Filename: 160-bandwidth-offset.txt
|
|
Title: Authorities vote for bandwidth offsets in consensus
|
|
Author: Roger Dingledine
|
|
Created: 4-May-2009
|
|
Status: Open
|
|
Target: 0.2.2.x
|
|
|
|
1. Motivation
|
|
|
|
As part of proposal 141, we moved the bandwidth value for each relay
|
|
into the consensus. Now clients can know how they should load balance
|
|
even before they've fetched the corresponding relay descriptors.
|
|
|
|
Putting the bandwidth in the consensus also lets the directory
|
|
authorities choose more accurate numbers to advertise, if we come up
|
|
with a better algorithm for deciding weightings.
|
|
|
|
Our original plan was to teach directory authorities how to measure
|
|
bandwidth themselves; then every authority would vote for the bandwidth
|
|
it prefers, and we'd take the median of votes as usual.
|
|
|
|
The problem comes when we have 7 authorities, and only a few of them
|
|
have smarter bandwidth allocation algorithms. So long as the majority
|
|
of them are voting for the number in the relay descriptor, the minority
|
|
that have better numbers will be ignored.
|
|
|
|
2. Options
|
|
|
|
One fix would be to demand that every authority also run the
|
|
new bandwidth measurement algorithms: in that case, part of the
|
|
responsibility of being an authority operator is that you need to run
|
|
this code too. But in practice we can't really require all current
|
|
authority operators to do that; and if we want to expand the set of
|
|
authority operators even further, it will become even more impractical.
|
|
Also, bandwidth testing adds load to the network, so we don't really
|
|
want to require that the number of concurrent bandwidth tests match
|
|
the number of authorities we have.
|
|
|
|
The better fix is to allow certain authorities to specify that they are
|
|
voting on bandwidth "offsets": how much they think the weight should
|
|
be changed for the relay in question. We should put the offset vote in
|
|
the stanza for the relay in question, so a given authority can choose
|
|
which relays to express preferences for and which not.
|
|
|
|
3. Security implications
|
|
|
|
If only some authorities choose to vote on an offset, then a majority of
|
|
those voting authorities can arbitrarily change the bandwidth weighting
|
|
for the relay. At the extreme, if there's only one offset-voting
|
|
authority, then that authority can dictate which relays clients will
|
|
find attractive.
|
|
|
|
This problem isn't entirely new: we already have the worry wrt
|
|
the subset of authorities that vote for BadExit.
|
|
|
|
To make it not so bad, we should deploy at least three offset-voting
|
|
authorities.
|
|
|
|
Also, authorities that know how to vote for offsets should vote for
|
|
an offset of zero for new nodes, rather than choosing not to vote on
|
|
any offset in those cases.
|
|
|
|
4. Design
|
|
|
|
First, we need a new consensus method to support this new calculation.
|
|
|
|
Now v3 votes can have a new weight on the "w" line:
|
|
"Bandwidth_Offset=" INT.
|
|
Once we're using the new consensus method, the new way to compute the
|
|
Bandwidth weight is by taking the old vote (explained in proposal 141:
|
|
median, then choose the lower number in the case of ties), and adding
|
|
or subtracting the median offset (using the offset closer to 0 in the
|
|
case of ties, and with a sum of 0 if the sum is negative).
|
|
|
|
Then the actual consensus looks just the same as it did before,
|
|
so clients never have to know that this additional calculation is
|
|
happening.
|
|
|