From 09c6ef487a20a1553afb58e891f40daacf17367e Mon Sep 17 00:00:00 2001 From: Roger Dingledine Date: Tue, 5 May 2009 08:53:12 -0400 Subject: add a new proposal for authorities to vote for bandwidth "offsets" --- proposals/160-bandwidth-offset.txt | 80 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 80 insertions(+) create mode 100644 proposals/160-bandwidth-offset.txt (limited to 'proposals/160-bandwidth-offset.txt') diff --git a/proposals/160-bandwidth-offset.txt b/proposals/160-bandwidth-offset.txt new file mode 100644 index 0000000..078754b --- /dev/null +++ b/proposals/160-bandwidth-offset.txt @@ -0,0 +1,80 @@ +Filename: 160-bandwidth-offset.txt +Title: Authorities vote for bandwidth offsets in consensus +Version: $Revision$ +Last-Modified: $Date$ +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. + -- cgit v1.2.3-54-g00ecf