[tor-bugs] #24674 [Core Tor/Torflow]: Bandwidth authorities should use geographically distributed bandwidth servers

[Tor Bug Tracker & Wiki]

#24674: Bandwidth authorities should use geographically distributed bandwidth
servers
------------------------------+---------------------
 Reporter:  teor              |          Owner:  tom
     Type:  task              |         Status:  new
 Priority:  Medium            |      Milestone:
Component:  Core Tor/Torflow  |        Version:
 Severity:  Normal            |     Resolution:
 Keywords:  tor-bwauth        |  Actual Points:
Parent ID:  #24499            |         Points:  3
 Reviewer:                    |        Sponsor:
------------------------------+---------------------

Comment (by teor):

 It's unclear whether the "average stream capacity regardless of path"
 includes the path from the client to the entry, and the exit to the
 internet server. Pragmatically, in the current design, it has to include
 client and internet server. (Or, in the case of onion services, client and
 service.)

 I don't know if this affects our design at all, but it should be clarified
 in the spec. I opened #24730 for this.

 Replying to [comment:2 mikeperry]:
 > We discussed this on tor-internal two years ago. The conclusion we came
 to then was that the simplest (and best) plan is to make the list of URLs
 in
 https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/bwauthority_child.py#n51
 contain a handful of fast, geographically distributed mirrors.
 >
 > This way, all bw authorities will use the same file servers, and the
 results that they produce for each relay should be an approximate
 arithmetic mean of its performance with each bandwidth file server (this
 is approximate because we do some measurement filtering, and because the
 choice of url is random, not strictly round robin:
 https://gitweb.torproject.org/torflow.git/tree/NetworkScanners/BwAuthority/bwauthority_child.py#n131).
 >
 > Then, for more diversity, we can move individual bw auths to
 geographically diverse locations. The result of this is that the directory
 authorities will take the median of their votes for each relay.
 >
 > The key advantage between this plan and just having each bw auth pick
 its own file server location is that we avoid having degenerate pairing
 effects of fast location to fast location, and we also avoid the need to
 do the full pairing combinations of (bw auth, file server) to achieve
 similar diversity with fixed pairings.
 >
 > I believe that controlling things in this way is also superior to
 surprise emergent effects of using a CDN.

 I am fine with this plan, as long as we are willing to set up servers in
 the relevant locations within a reasonable amount of time.

 I am also fine with using a CDN, because it's a fast way to get access to
 a large number of locations. And CDNs are already used for significant
 amounts of actual Tor client traffic, so excluding them might create less
 accurate results.

 Unless there's a show-stopper here, let's document the pros and cons, and
 leave the choice up to the (bandwidth) authority operators?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24674#comment:3>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online