Opened 9 years ago

Closed 9 years ago

Last modified 8 years ago

#4489 closed defect (fixed)

AuthDirFastGuarantee is too low, harming performance

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: performance loadbalancing tor-auth
Cc: mikeperry, karsten Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Right now the bandwidth cutoff to guarantee the Fast flag (see #4484) is 20KB. That means anybody with 20KB or more of capacity gets the Fast flag for sure.

But our design had in mind that we'd adapt the assignment of the Fast flag to grow as the relays grew, such that the top 7/8 of the relays got it. The guarantee was intended to be a security defense against a Sybil flooding the network with enough lying relays to push out most honest relays.

At the time we picked 20KB for the guarantee, that was the value for the 7/8 mark. But right now moria1 would vote the Fast flag only for relays with 32KB of capacity or more, if it weren't constrained by this 20KB guarantee.

I think we should change AuthDirFastGuarantee to 100KB while we await performance analysis to answer questions like the ones posed in #3946.

Child Tickets

Change History (11)

comment:1 Changed 9 years ago by arma

Keywords: performance, loadbalancingperformance loadbalancing

comment:2 Changed 9 years ago by arma

Status: newneeds_review

See branch bug4489 in my git repo.

(This branch builds on the #4484 branch.)

comment:3 Changed 9 years ago by arma

Cc: mikeperry added

Mike, please tell us your level of excitement here.

comment:4 Changed 9 years ago by arma

Cc: karsten added

Also, Karsten it would be great to get a current count from you of a) how many relays have >=20KB but <32KB of descriptor capacity, b) what fraction of total descriptor capacity they represent, and c) what fraction of consensus capacity they represent. Unless these answers are hard to get, in which case, never mind. :)

comment:5 Changed 9 years ago by karsten

I looked at the consensus published on November 16 at 12:00:00 UTC. (I also briefly looked at the other consensuses published on that day to see that the 12:00 numbers aren't totally off. If you want to see how these numbers change over time, please let me know. But it's going to take more effort.)

There were 251 out of 2429 relays with an advertised bandwidth (the lower number of average and observed bandwidth) >= 20 KiB and < 32 KiB. That's a fraction of 10.33 % of all relays. These relays represent 0.31 % of the total advertised bandwidth or 0.04 % of the consensus bandwidth of all relays running at the time.

comment:6 Changed 9 years ago by nickm

Looks okay to me, modulo comment on #4484 about how this needs a manpage entry. (Also, if dir-spec.txt mentions the old values here, we should update it to say that they're parameterizable, and default to something new now.)

comment:7 Changed 9 years ago by mikeperry

My thinking is that in an ideal situation, we'd assign Fast based solely on the top 7/8 measured consensus values, setting this value high enough to not normally apply (at let's say, 90% of the current Fast capacity?). This would keep the bulk of the network bandwidth permanent in the face of the attack, but not have this artificial minimum dragging us down most of the time.

comment:8 Changed 9 years ago by arma

Milestone: Tor: 0.2.2.x-finalTor: 0.2.3.x-final
Resolution: fixed
Status: needs_reviewclosed

Merged it. I picked master rather than maint-0.2.2, so we can try it out first.

(Also, 4 out of 8 dir auths are on master already, so if they all upgrade then the 4 dir auths on 0.2.2 won't produce enough votes for Fast. So maybe we don't need to backport it at all -- assuming we don't mind some flapping.)

comment:9 Changed 9 years ago by arma

I also updated the dir-spec to say the new value.

comment:10 Changed 8 years ago by nickm

Keywords: tor-auth added

comment:11 Changed 8 years ago by nickm

Component: Tor Directory AuthorityTor
Note: See TracTickets for help on using tickets.