|
|
= So You Want to Fix the Tor Network: Episode Three =
|
|
|
= - or - =
|
|
|
= Does a Bandwidth Authority Really Matter? =
|
|
|
# So You Want to Fix the Tor Network: Episode Three
|
|
|
# - or -
|
|
|
# Does a Bandwidth Authority Really Matter?
|
|
|
|
|
|
So you've [[BandwidthAuthority|set up a bandwidth authority]].
|
|
|
|
|
|
Now what happens to the tor network?
|
|
|
|
|
|
== What does Bandwidth Measurement Optimise? ==
|
|
|
## What does Bandwidth Measurement Optimise?
|
|
|
|
|
|
The goal of the bandwidth authorities is to balance load across the
|
|
|
network such that a user can expect to have the same average stream
|
... | ... | @@ -21,14 +21,14 @@ So the Tor network should give an equal share of bandwidth to each relay, based |
|
|
TODO:
|
|
|
* work out how to measure how successful we are
|
|
|
|
|
|
=== What other things might we want bandwidth measurement to optimise? ===
|
|
|
### What other things might we want bandwidth measurement to optimise?
|
|
|
|
|
|
Using the Tor network needs to be a good experience for clients. This means:
|
|
|
* maximising throughput, and
|
|
|
* minimising latency.
|
|
|
Different clients have different needs: a SSH or IRC client wants low latency, but a big download wants throughput. Tor 0.2.9.8 and later try to prioritise interactive sessions over bulk transfers.
|
|
|
|
|
|
== What do Bandwidth Authorities Measure? ==
|
|
|
## What do Bandwidth Authorities Measure?
|
|
|
|
|
|
Tor bandwidth scanners measure download speed by downloading files. The scanner is a Tor client that connects to a bandwidth server using a two-hop path. The path has one Guard/Middle node, and one Exit. These relays are selected from a group of relays with similar bandwidths. The scanner uses larger files for relays with larger bandwidths.
|
|
|
|
... | ... | @@ -38,7 +38,7 @@ The throughput of the circuit depends on the spare throughput of both relays in |
|
|
|
|
|
Circuit latency adds to the connection setup time. It also takes longer for the client to ask for more data. The time it takes to build the circuit depends on the latency between the scanner, the entry, the exit, and the bandwidth server. Busy relays can be slow sending data to the network, or drop packets. Dropped packets need to be re-sent from the end of the circuit. Even if there is no congestion, tor clients still need ask for more data. (TODO: what is the limit on SENDME cells?)
|
|
|
|
|
|
== Overall Network Improvements ==
|
|
|
## Overall Network Improvements
|
|
|
|
|
|
An extra bandwidth authority makes all the bandwidth measurements for the tor network more stable.
|
|
|
|
... | ... | @@ -46,7 +46,7 @@ The relay measurement is the median of all the different authority measurements |
|
|
|
|
|
A graph of the relays that are the median for each bandwidth authority is in #21882.
|
|
|
|
|
|
== Should I put a bandwidth server on IPv6? ==
|
|
|
## Should I put a bandwidth server on IPv6?
|
|
|
|
|
|
We think so. Tor Browser sets PreferIPv6 on its SOCKSPorts, so Exits connect via IPv6 if it is available. We want to do this for bandwidth scanners, so they measure what clients see (#21995).
|
|
|
|
... | ... | @@ -61,11 +61,11 @@ That way, IPv4-only exits get measured 100% via IPv4, and dual-stack exits get m |
|
|
|
|
|
We don't want to add IPv6 literals or IPv6-only addresses, because IPv4-only Exits will fail on those addresses.
|
|
|
|
|
|
== Does Bandwidth Authority Location Matter? ==
|
|
|
## Does Bandwidth Authority Location Matter?
|
|
|
|
|
|
Yes! Tor sends more Guard and Middle bandwidth to relays close to the bandwidth scanner, and more Exit bandwidth to relays close to the bandwidth server.
|
|
|
|
|
|
=== Current Bandwidth Authority Locations ===
|
|
|
### Current Bandwidth Authority Locations
|
|
|
|
|
|
All of the current bandwidth scanners are in North America or Europe, and most of the bandwidth servers are in North America or Europe, with one in Asia.
|
|
|
|
... | ... | @@ -73,7 +73,7 @@ We're working to change this, by putting bandwidth servers (and scanners) on oth |
|
|
|
|
|
(TODO: add a table with actual locations, if the operators are ok with that)
|
|
|
|
|
|
=== How does Location Impact Tor Clients? ===
|
|
|
### How does Location Impact Tor Clients?
|
|
|
|
|
|
The current bandwidth authority locations mean that relays in North America and Europe handle more traffic:
|
|
|
* The Tor network is faster for all clients. Clients are more likely to choose a path with relays that are near each other. This affects hidden services the most, because they have 6-hop long paths.
|
... | ... | @@ -82,11 +82,11 @@ The current bandwidth authority locations mean that relays in North America and |
|
|
* Websites with servers in North America or Europe are faster through Tor Exits (on average).
|
|
|
* Websites that use a CDN are faster if the CDN DNS sends the connection to nearby data center, and if the CDN has many servers in North America or Europe.
|
|
|
|
|
|
=== Bandwidth Authorities Outside North America / Europe ===
|
|
|
### Bandwidth Authorities Outside North America / Europe
|
|
|
|
|
|
Adding or moving bandwidth authorities changes relay measurements: relays closer to the new location will be measured higher. A bandwidth scanner affects Guard and Middle measurements. A bandwidth server affects Exit measurements.
|
|
|
|
|
|
==== A Quick Example: CDN ====
|
|
|
#### A Quick Example: CDN
|
|
|
|
|
|
Using a CDN as a bandwidth server spreads the load from exits around the world. It avoids concentrating exit bandwidth near existing bandwidth servers in the US and Western Europe. This should also move entry and middle bandwidth further away from the scanners in these areas.
|
|
|
|
... | ... | @@ -97,7 +97,7 @@ Here's how we can avoid this issue: |
|
|
* use different CDNs for different scanners,
|
|
|
* configure the bandwidth scanner with a CDN, and with other bandwidth servers that aren't in one of the CDN data centers.
|
|
|
|
|
|
==== A Detailed Example: South America ====
|
|
|
#### A Detailed Example: South America
|
|
|
|
|
|
(TODO: too much detail?)
|
|
|
|
... | ... | |