[tor-commits] [torspec/master] Add a new proposal to help us move forward with 275.

[nickm at torproject.org]

commit a323d84e7c8b83676010dd78554a455ad2f869ce
Author: Nick Mathewson <nickm at torproject.org>
Date:   Wed May 30 17:19:54 2018 -0700

    Add a new proposal to help us move forward with 275.
---
 proposals/000-index.txt                |  2 ++
 proposals/293-know-when-to-publish.txt | 58 ++++++++++++++++++++++++++++++++++
 2 files changed, 60 insertions(+)

diff --git a/proposals/000-index.txt b/proposals/000-index.txt
index b70e998..2d7a595 100644
--- a/proposals/000-index.txt
+++ b/proposals/000-index.txt
@@ -213,6 +213,7 @@ Proposals by number:
 290  Continuously update consensus methods [OPEN]
 291  The move to two guard nodes [OPEN]
 292  Mesh-based vanguards [OPEN]
+293  Other ways for relays to know when to publish [OPEN]
 
 
 Proposals by status:
@@ -273,6 +274,7 @@ Proposals by status:
    290  Continuously update consensus methods
    291  The move to two guard nodes
    292  Mesh-based vanguards
+   293  Other ways for relays to know when to publish [for 0.3.5]
  ACCEPTED:
    172  GETINFO controller option for circuit information
    173  GETINFO Option Expansion
diff --git a/proposals/293-know-when-to-publish.txt b/proposals/293-know-when-to-publish.txt
new file mode 100644
index 0000000..4a46730
--- /dev/null
+++ b/proposals/293-know-when-to-publish.txt
@@ -0,0 +1,58 @@
+Filename: 293-know-when-to-publish.txt
+Title: Other ways for relays to know when to publish
+Author: Nick Mathewson
+Created: 30-May-2018
+Status: Open
+Target: 0.3.5
+
+
+1. Motivation
+
+   In proposal 275, we give reasons for dropping the published-on
+   field from consensus documents, to improve the performance of
+   consensus diffs.  We've already changed Tor (as of 0.2.9.11) to
+   allow us to set those fields far in the future -- but
+   unfortunately, there is still one use case that requires them:
+   relays use the published-on field to tell if they are about to fall
+   out of the consensus and need to make new descriptors.
+
+   Here we propose two alternative mechanisms for relays to know that
+   they should publish descriptors, so we can enact proposal 275 and
+   set the published-on field to some time in the distant future.
+
+
+2. Mechanism One: The StaleDesc flag
+
+   Authorities should begin voting aon a new StaleDesc flag.
+
+   When authorities vote, if the most recent published_on date for
+   a descriptor has over DESC_IS_STALE_INTERVAL in the past, the
+   authorities should vote to give the StaleDesc flag to that relay.
+
+   If any relay sees that it has the StaleDesc flag, it should upload
+   some time in the first half of the voting interval.  (Implementors
+   should take care not to re-upload over and over, though: Relays won't
+   lose the flag until the next voting interval is reached.)
+
+   (Define DESC_IS_STALE_INTERVAL as equal to
+   FORCE_REGENERATE_DESCRIPTOR_INTERVAL.)
+
+
+3. Mechanism Two: Uploading more frequently when rejected.
+
+   Tor relays should remember the last time at which they uploaded a
+   descriptor that was accepted by a majority of dirauths.  If this
+   time is more than FAST_RETRY_DESCRIPTOR_INTERVAL in the past, we
+   mark our descriptor as dirty from
+   mark_my_descriptor_dirty_if_too_old().
+
+
+4. Implications for proposal 275
+
+   Once most relays are running verions that support the features
+   above, and once authorities are generating consensuses with the
+   StaleDesc flag, there will no longer be a need to keep the
+   published time in consensus documents accurate -- we can start
+   setting it to some time in the distant future, per proposal 275.
+
+