mirror of
https://gitlab.torproject.org/tpo/core/tor.git
synced 2024-11-28 06:13:31 +01:00
d230827912
Tor doesn't use SVN anymore, making $Revision$, $Id$ and $Date$ meaningless. Remove them without replacement.
40 lines
1.3 KiB
Plaintext
40 lines
1.3 KiB
Plaintext
Filename: 145-newguard-flag.txt
|
|
Title: Separate "suitable as a guard" from "suitable as a new guard"
|
|
Author: Nick Mathewson
|
|
Created: 1-Jul-2008
|
|
Status: Open
|
|
Target: 0.2.1.x
|
|
|
|
[This could be obsoleted by proposal 141, which could replace NewGuard
|
|
with a Guard weight.]
|
|
|
|
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.
|