<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>