2008-07-02 20:04:01 +02:00
|
|
|
Filename: 145-newguard-flag.txt
|
|
|
|
|
Title: Separate "suitable as a guard" from "suitable as a new guard"
|
|
|
|
|
Version: $Revision$
|
|
|
|
|
Last-Modified: $Date$
|
|
|
|
|
Author: Nick Mathewson
|
|
|
|
|
Created: 1-Jul-2008
|
2008-07-02 21:17:51 +02:00
|
|
|
Status: Open
|
2008-07-02 20:04:01 +02:00
|
|
|
|
2008-07-11 19:08:11 +02:00
|
|
|
[This could be obsoleted by proposal 141, which could replace NewGuard
|
|
|
|
|
with a Guard weight.]
|
|
|
|
|
|
2008-07-02 20:04:01 +02:00
|
|
|
Overview
|
|
|
|
|
|
|
|
|
|
Right now, Tor has one flag that clients use both to tell which
|
|
|
|
|
nodes should be kept as guards, and which nodes should be picked
|
|
|
|
|
when choosing new guards. This proposal separates this flag into
|
|
|
|
|
two.
|
|
|
|
|
|
|
|
|
|
Motivation
|
|
|
|
|
|
|
|
|
|
Balancing clients amoung guards is not done well by our current
|
|
|
|
|
algorithm. When a new guard appears, it is chosen by clients
|
|
|
|
|
looking for a new guard with the same probability as all existing
|
|
|
|
|
guards... but new guards are likelier to be under capacity, whereas
|
|
|
|
|
old guards are likelier to be under more use.
|
|
|
|
|
|
|
|
|
|
Implementation
|
|
|
|
|
|
|
|
|
|
We add a new flag, NewGuard. Clients will change so that when they
|
|
|
|
|
are choosing new guards, they only consider nodes with the NewGuard
|
|
|
|
|
flag set.
|
|
|
|
|
|
|
|
|
|
For now, authorities will always set NewGuard if they are setting
|
|
|
|
|
the Guard flag. Later, it will be easy to migrate authorities to
|
|
|
|
|
set NewGuard for underused guards.
|
|
|
|
|
|
|
|
|
|
Alternatives
|
|
|
|
|
|
|
|
|
|
We might instead have authorities list weights with which nodes
|
|
|
|
|
should be picked as guards.
|
