[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: Implementing proposal 147: Eliminate the need for v2 directories in generating v3 directories



On 5/18/10 3:16 PM, Roger Dingledine wrote:
> On Tue, May 18, 2010 at 11:18:19AM +0200, Karsten Loesing wrote:
>> Sebastian and I think that we really need this proposal to be
>> implemented in Tor soon, because we're running out of v2 authorities.
>> Only 2 of them are still running: tor26 and dizum. Time to get rid of v2.
>>
>> - Set up 3 v3 directory authorities and 1 relay. Configure the relay
>> with only 1 of the directory authorities. Watch how the relay is not
>> contained in the first consensus, but in the second.
> 
> Make sure you use 0.2.2.12-alpha or later for these tests (and for
> directory authorities in general). That's where I added:
>     - Many relays have been falling out of the consensus lately because
>       not enough authorities know about their descriptor for them to get
>       a majority of votes. When we deprecated the v2 directory protocol,
>       we got rid of the only way that v3 authorities can hear from each
>       other about other descriptors. Now authorities examine every v3
>       vote for new descriptors, and fetch them from that authority. Bugfix
>       on 0.2.1.23.
> 
> In short, in the scenario you describe above, in earlier versions they
> only discover new descriptors in the consensus itself, not the votes --
> so since it isn't in the first, nobody else ever learns to fetch the
> descriptor, so it's never in later consensuses either.

Yes, we discovered that somewhat unexpected behavior when setting up the
test case with 3 authorities and a relay knowing only 1 of them. The
authorities started exchanging votes within 1 second of time (depending
on when they enter their 1-second main loop), and if the authority the
relay knows about was first, the others learned about the relay. We
fixed our test case by delaying uploading votes on the first authority
by 5 seconds.

>> - Write code to process v3 opinions. This includes verifying signatures
>> and downloading missing descriptors from the authority that sent the
>> opinion.
> 
> git show 2e692bd8c98c841a
> for how I did the earlier changes.
> 
> I wonder what would happen if we simply generate a vote at :45 and send
> it, and then generate another vote at :50 and send that? It seems like at
> the least we could reuse nearly all of the vote-generating and -parsing
> code. I'll grant that we might want to declare the actual document to
> be something other than a "vote", in case things can go bad when we've
> received two votes from a single authority.

I'm hoping that we can re-use 99% of the vote-generating and -parsing
code. Still, adopting the features in phases might be useful.

>> - Add an opinion-exchanging phase preceding the vote-exchanging phase.
>> With default values, the voting phase is from :50 to :55, so that the
>> opinion phase would be :45 to :50. Add config options to adjust the
>> length of this new phase.
> 
> You'll also like the feature I added in eaf5487d9570fb that makes
> the authority fetch the missing descriptor from the source of the vote
> it's reading (rather than from a random authority).

Yup. Sebastian mentioned that commit and the one above.

Best,
--Karsten