commit a323d84e7c8b83676010dd78554a455ad2f869ce Author: Nick Mathewson <nickm@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. + +