<div dir="auto">I didn't get <div dir="auto">Iam in or out</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu 31 May, 2018, 5:49 AM Nick Mathewson, <<a href="mailto:nickm@torproject.org">nickm@torproject.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Filename: 293-know-when-to-publish.txt<br>
Title: Other ways for relays to know when to publish<br>
Author: Nick Mathewson<br>
Created: 30-May-2018<br>
Status: Open<br>
Target: 0.3.5<br>
<br>
<br>
1. Motivation<br>
<br>
In proposal 275, we give reasons for dropping the published-on<br>
field from consensus documents, to improve the performance of<br>
consensus diffs. We've already changed Tor (as of 0.2.9.11) to<br>
allow us to set those fields far in the future -- but<br>
unfortunately, there is still one use case that requires them:<br>
relays use the published-on field to tell if they are about to fall<br>
out of the consensus and need to make new descriptors.<br>
<br>
Here we propose two alternative mechanisms for relays to know that<br>
they should publish descriptors, so we can enact proposal 275 and<br>
set the published-on field to some time in the distant future.<br>
<br>
<br>
2. Mechanism One: The StaleDesc flag<br>
<br>
Authorities should begin voting aon a new StaleDesc flag.<br>
<br>
When authorities vote, if the most recent published_on date for<br>
a descriptor has over DESC_IS_STALE_INTERVAL in the past, the<br>
authorities should vote to give the StaleDesc flag to that relay.<br>
<br>
If any relay sees that it has the StaleDesc flag, it should upload<br>
some time in the first half of the voting interval. (Implementors<br>
should take care not to re-upload over and over, though: Relays won't<br>
lose the flag until the next voting interval is reached.)<br>
<br>
(Define DESC_IS_STALE_INTERVAL as equal to<br>
FORCE_REGENERATE_DESCRIPTOR_INTERVAL.)<br>
<br>
<br>
3. Mechanism Two: Uploading more frequently when rejected.<br>
<br>
Tor relays should remember the last time at which they uploaded a<br>
descriptor that was accepted by a majority of dirauths. If this<br>
time is more than FAST_RETRY_DESCRIPTOR_INTERVAL in the past, we<br>
mark our descriptor as dirty from<br>
mark_my_descriptor_dirty_if_too_old().<br>
<br>
<br>
4. Implications for proposal 275<br>
<br>
Once most relays are running verions that support the features<br>
above, and once authorities are generating consensuses with the<br>
StaleDesc flag, there will no longer be a need to keep the<br>
published time in consensus documents accurate -- we can start<br>
setting it to some time in the distant future, per proposal 275.<br>
_______________________________________________<br>
tor-dev mailing list<br>
<a href="mailto:tor-dev@lists.torproject.org" target="_blank" rel="noreferrer">tor-dev@lists.torproject.org</a><br>
<a href="https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev" rel="noreferrer noreferrer" target="_blank">https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev</a><br>
</blockquote></div>