Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#17905 closed enhancement (fixed)

Consider removing fallback directory weights

Reported by: teor Owned by:
Priority: Medium Milestone: Tor: 0.2.8.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: must-fix-before-028-rc, TorCoreTeam201605
Cc: s7r, Sebastian Actual Points: 8 hours
Parent ID: #17158 Points: 0.4
Reviewer: Sponsor: SponsorU-can

Description

We don't currently weight requests to authorities.

While the fallback directory code uses the weights, we could assign each fallback the same weight, or leave the weights out, and have them assigned the default weight.

If we didn't weight fallback directories, this would potentially improve:

  • the statistics calculations on authorities,
  • the privacy implications of high-weighted fallbacks seeing too many client requests.

(Implementing this ticket would obsolete #17888.)

Child Tickets

Change History (17)

comment:1 Changed 4 years ago by nickm

I'm inclined to wontfix this one. IME, back 10 years ago when Tor had no weights at all, it was a big mess. Clients were putting way too much load on some relays while others were underused.

comment:2 Changed 4 years ago by teor

Keywords: CoreTorTeam201602 removed
Resolution: wontfix
Status: newclosed

I agree, I don't like the idea of overloading low-weight fallback directories.
We'll likely have at least a 10x difference between the highest and lowest weight fallbacks.

comment:3 Changed 4 years ago by s7r

Cc: s7r Sebastian added
Resolution: wontfix
Status: closedreopened

I will reopen this ticket for one last debate given teor is getting close on coding it.

Me and Sebastian think we should not hardcode any weights for the fallback directories, and give the very same probability for each fallback directory to be randomly picked by a client. We split the load from 9 servers to 100(+9) servers. If one fallback directory mirror is not fast enough to handle the extra load required by this, it shouldn't be on the list in the first place.

Totally agree with nick, weights are very important for path selection and circuit creation / probability to be picked in a circuit. But this is something different, one-time per client at initial bootstrap (we have directory guards once we have a consensus) and I think we can make an exception here.

Additional advantage is that we only have to maintain a list of fallback relays, not also weights which are subject to constant change (relay's internet connection breaks, DDoS, bwauths can't measure it, fraction in consensus changes, etc.).

comment:4 Changed 4 years ago by teor

Parent ID: #17158

comment:5 Changed 4 years ago by nickm

Milestone: Tor: 0.2.8.x-finalTor: 0.2.???

It is impossible that we will fix all 277 currently open 028 tickets before 028 releases. Time to move some out. This is my first pass through the "new" and "reopened" tickets, looking for things to move to ???.

comment:6 Changed 4 years ago by arma

Another improvement from removing the weights is, counterintuitively, better load balancing. We pick our weights right now based on consensus numbers, right? And those are a) wildly wrong because bwauth is wildly wrong, and b) wildly variable over time, yet we pick one snapshot and pretend the network will be close enough to like that for months into the future. I could totally imagine a situation where a fast fallbackdir gets 5% of the weight, and then it goes slow some weeks later. That's easier to imagine than the bwauth pulls a bunch of numbers out of a hat and they turn out to be good numbers some weeks later. Let's not paint ourselves into that corner.

All of this said, maybe the compromise for 0.2.8 is to leave all the machinery in place, but ship it with much simpler weights for the fallbackdirs?

I think Sebastian and s7r make a good point that we should pick relays that are capable of serving the consensus to clients, and so long as all of the relays are above some minimum bar, things should work well enough.

comment:7 in reply to:  6 ; Changed 4 years ago by teor

Replying to arma:

All of this said, maybe the compromise for 0.2.8 is to leave all the machinery in place, but ship it with much simpler weights for the fallbackdirs?

I think Sebastian and s7r make a good point that we should pick relays that are capable of serving the consensus to clients, and so long as all of the relays are above some minimum bar, things should work well enough.

I propose that we weight each fallback directory "10.0", so each fallback directory is ten times more likely to be chosen than any authority. (The default weight of authorities is "1.0".)

This also involves increasing the minimum consensus weight required to be a fallback directory. (Which means a minor redesign of that part of the script.)

It's worth noting that we still don't have enough fallback directories. I'll be emailing operators on their ContactInfo and asking them to opt-in (#17158).

comment:8 Changed 4 years ago by teor

Keywords: must-fix-before-028-rc added
Milestone: Tor: 0.2.???Tor: 0.2.8.x-final

We have to make a decision on this before 0.2.8-rc, as it's the first release with default fallbacks.

(That said, if we decide later that we don't want weights, we can nuke them in a point release. But that only works for clients from then on.)

comment:9 Changed 4 years ago by s7r

I am totally for removing the hard coded weights and keep it this way.

The weight of relays is dynamic data, subject to change from one consensus to another, I don't think we get any benefit by hard coding such data. If all hard coded fallback directories will be above some minimum threshold, they will handle the clients just fine.

comment:10 Changed 4 years ago by tscpd

Just thoughts. Could it be a compromise to group fallbacks by weight? This way the majority of dir-requests will be lead to the majority of the fallbacks. Instead of giving a high amount of requests to the few very high weighted fallbacks we could assign them a lower amount of requests. Also we could assign a lower amount of requests to very low weighted fallbacks.

Group1 fallbacks weight 0-7.500 10%
Group2 fallbacks weight 7.500-17.500 70%
Group3 fallbacks weight 17.500-200.000 10%
Group4 Authorities 10%

comment:11 in reply to:  7 Changed 4 years ago by teor

Actual Points: 8 hours
Points: small-remaining

Replying to teor:

Replying to arma:

I think Sebastian and s7r make a good point that we should pick relays that are capable of serving the consensus to clients, and so long as all of the relays are above some minimum bar, things should work well enough.

I propose that we weight each fallback directory "10.0", so each fallback directory is ten times more likely to be chosen than any authority. (The default weight of authorities is "1.0".)

I also propose that we make the minimum consensus weight 3000. This is (nominally) 100 times the expected extra load of 30 kilobytes per second = 50GB per month.

In #17158, I've emailed operators of fallback candidates with weights 30,000 and greater, and I'm considering contacting those between 3000 and 30,000 if I need to make up numbers.

I think this change is a good idea because equal weighting:

  • makes the security / privacy analysis easier,
  • makes for better load balancing as the list ages, consensus weights change, and relays go down, and
  • simplifies the script.

There are also minor benefits for statistics collection.

I'll submit the fix with #17158.

comment:12 Changed 4 years ago by teor

Status: reopenedneeds_review

Resolved by 205a641e1dad6db967825dcad01bc59c6909b395 in fallbacks-201604-v9 in #17158.

The related 78ec782f76d4e228761128f24589316276e80473 in fallbacks-201604-v9 ensures that each fallback has a bandwidth of 3MB/s, which is ~100 times the expected extra load of 20-30KB/s (50GB/month).

Edit: my branches are on https://github.com/teor2345/tor.git

Last edited 4 years ago by teor (previous) (diff)

comment:13 Changed 4 years ago by teor

Sponsor: SponsorU-can

comment:14 Changed 4 years ago by teor

(This has been merged to maint-0.2.8 and can be closed after review if there are no issues.)

comment:15 Changed 4 years ago by nickm

Keywords: TorCoreTeam201605 added

Calling all non-needs_information tickets for May.

comment:16 Changed 4 years ago by teor

Resolution: fixed
Status: needs_reviewclosed

This has been merged to 0.2.8.

comment:17 Changed 4 years ago by isabela

Points: small-remaining0.4
Note: See TracTickets for help on using tickets.