[tor-dev] Review of Proposal 147: Eliminate the need for v2 directories in generating v3 directories

[Karsten Loesing]

On 1/15/14 1:08 PM, Karsten Loesing wrote:
> On 1/6/14 7:55 PM, Nick Mathewson wrote:
>> On Tue, Dec 24, 2013 at 3:55 AM, Karsten Loesing <karsten at torproject.org> wrote:
>>> On 12/17/13 10:31 PM, Nick Mathewson wrote:
>>>> 147  Eliminate the need for v2 directories in generating v3 directories
>>>>
>>>>      This proposal explains a way that we can phase out the
>>>>      vestigial use of v2 directory documents in keeping authorities
>>>>      well-informed enough to generating the v3 consensus.  It's
>>>>      still correct; somebody should implement it before the v2
>>>>      directory code rots any further. (5/2011)
>>>
>>> This proposal looks plausible to me.  Some minor remarks:
>>>
>>> - The proposal suggests that authorities send an opinion document to the
>>> other authorities "at the regular vote upload URL".  URLs are cheap, why
>>> not use a different URL to keep things separated, e.g., /tor/post/opinion ?
>>
>> sure.
> 
> Okay, starting a patch with proposal 147 tweaks and changing this URL as
> suggested.
> 
>>> - Should dir-spec.txt suggest a timing for pushing-and-pulling opinion
>>> documents?  Authorities could send their opinions at :45:00 and fetch
>>> missing opinions at :47:30.  This could be defined by a new
>>> OpinionSeconds part contained in "voting-delay" lines.  This would be a
>>> SHOULD requirement, not a MUST requirement.
>>
>> This is plausible.
> 
> Added to the proposal.
> 
>>> - The proposal doesn't say what lines must be contained in opinion
>>> documents.  It seems that an authority that parses an opinion document
>>> is only interested in a) relay fingerprint, b) descriptor publication
>>> time, and c) descriptor digest; unless there's more information that
>>> helps authorities decide whether "they might accept" a descriptor.  If
>>> not, opinion documents only need to contain a small subset of headers
>>> and all the "r" lines that would be contained in a later vote.
>>
>> This also seems okay.  It would however mean that we can't use the
>> same parsing logic as we use for regular votes.
> 
> True.  Added as two comments to the proposal.
> 
>>> - The proposal doesn't explicitly say this, so just to be sure: when an
>>> authority finds that it's missing a router descriptor that it then
>>> downloads, it also downloads the corresponding extra-info descriptor
>>> afterwards, right?
>>
>> I suppose it should.
> 
> Added.
> 
>>> - Another thing that is left implicit in the proposal: the opinion
>>> document will always contain the valid-after time of the *next*
>>> consensus.  Well, the URL /tor/status-vote/next/opinion implies that,
>>> but maybe we should explicitly mention this in dir-spec.txt.
>>
>> Hm. maybe valid-after and valid-until should just get ignored on
>> opinions. Or omitted.
> 
> Added as comments.
> 
>> Also, ISTR that Roger told me that this whole proposal didn't actually
>> seem to be necessary in practice. I wish I could remember the
>> rationale, though.
> 
> I talked to Roger on IRC, and here's why this proposal may indeed be
> overkill:
> 
> As of January 2013, there is only a single version 3 directory authority
> left that serves version 2 statuses: dizum.  moria1 and tor26 have been
> rejecting version 2 requests for a long time, and it's mostly an
> oversight that dizum still serves them.  The other six authorities have
> never generated version 2 statuses for others to be used as pre-voting
> opinions.  So, it's basically not true that version 2 statuses are
> required for the version 3 protocol to work properly.
> 
> Here's a possible way to move this forward.
> 
> - Please review and merge my prop147tweaks branch that contains tweaks
> from our discussion above, regardless of whether this proposal will be
> implemented or not.
> 
> - I'm going to run a quick analysis of archived vote documents to see
> how much authorities would have benefited from the others' votes before
> generating their own votes.

>From January 1 to 7, 2014, only 0.4 relays on average were not included
in a consensus because they were listed in less than 5 votes.  These 0.4
relays could probably have been included with pre-voting opinions.

(Here's how I found out: extract the votes-2014-01.tar.bz2 tarball, run
`grep -R "^r " 0[1-7] | cut -c 4-22,112- | cut -d" " -f1,3 | sort | uniq
-c | sort | grep " [1-4] " | wc -l`, result is 63, divide by 7*24
published consensuses, obtain 0.375 as end result.)

> - I'm going to ask Alex to disable version 2 statuses on dizum using
> DisableV2DirectoryInfo_ 1 to see what that does to the network.  We
> should probably finish the 2048 bits RSA keys upgrade first before
> changing yet another variable.
> 
> - If there's no convincing argument to implement opinion documents, we
> close this proposal as rejected.
> 
> What do you think?
> 
> All the best,
> Karsten
> 
>