Opened 9 months ago

Last modified 9 months ago

#28807 new enhancement

Ask authority operators to set `MaxAdvertisedBandwidth 0` in their torrcs

Reported by: wagon Owned by:
Priority: Medium Milestone:
Component: Core Tor/DirAuth Version:
Severity: Normal Keywords: tor-client, tor-dirauth, tor-bwauth
Cc: arma Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Currently, it seems that Tor clients don't use DA nodes for construction of circuits because all DA's bandwidth is set to 20, which is a very low value. To move unneeded client traffic out of DA nodes completely, we could have some torrc option on client's side (which disables construction of such circuits) and on DA's side (which block client's requests to use the DA as a node in its circuits). Additionally, use of DA nodes in clients circuits may be governed by some consensus values published by DA nodes.

In general, in testing Tor network with a small number of nodes, enabling this option may be undesirable, but in the main Tor network it may help DA nodes to decrease their load. Also, this explicit solution may be more clean than the current probabilistic approach which relies on a small bandwidth value set for DA nodes.

This task was originally discussed in another comment with teor.

Child Tickets

TicketTypeStatusOwnerSummary
#19011defectnewUse of maxunmeasuredbw and bwweightscale is broken in consensus

Change History (5)

comment:1 in reply to:  description ; Changed 9 months ago by teor

Component: Core Tor/TorCore Tor/DirAuth
Keywords: tor-doc tor-spec removed
Summary: Use of Directory Authorities in usual circuits may need an option to be disabledAsk authority operators to set `MaxAdvertisedBandwidth 0` in their torrcs
Version: Tor: 0.3.4.9

Replying to wagon:

Currently, it seems that Tor clients don't use DA nodes for construction of circuits because all DA's bandwidth is set to 20, which is a very low value.

That's not strictly true, and the details are important.

20 is the maximum consensus weight for an unmeasured relay, set by tor authorities.

Most unmeasured relays have weights of:

  • 0 (self-reported 0 bandwidth) or
  • 20 (self-reported a bandwidth of 20 or higher):

https://github.com/torproject/tor/blob/1eb3719a62074baef97ec1aa5c144096706fb97f/src/feature/dirauth/dirvote.c#L1498

Secondly, the total consensus weight right now is 58103330:

$ cat path/to/cached-microdesc-consensus | grep "^w " | cut -d= -f2 | cut -d" " -f1 | paste -s -d+ - | bc
58103330

There are 10 authorities with a consensus weight of 20:
https://metrics.torproject.org/rs.html#search/flag:Authority

There are approximately 2 million Tor clients:
https://metrics.torproject.org/userstats-relay-country.html

Therefore, each time every client makes a circuit, this many clients will choose an authority:

20*10*2000000/58103330 = 6.9

(Authorities are only chosen as middle nodes, because they don't have any other relevant flags.)

So I'm not sure this is a big problem. It probably doesn't deserve much effort from us.

  1. Here's one way we could fix it:
    1. Introduce a new consensus method that supports the bwweightscale and maxunmeasuredbw consensus parameters properly (#19011)
    2. Convince directory authority operators to set maxunmeasuredbw to:
      • 1 (0.34 clients choosing an authority each time every client builds 1 circuit), or
      • 0 (no clients choosing authorities for circuits)

But this change affects all unmeasured relays, not just authorities.

  1. Here's another way we could fix it:
    1. Convince directory authority operators to set MaxAdvertisedBandwidth 0 in their torrcs

Since authorities are unmeasured, tor will use min(self-reported bandwidth, MaxAdvertisedBandwidth, 20) as their bandwidth. sbws and Torflow never produce results for authorities, so they will always be unmeasured. (sbws 1.0.3 and later will also apply the MaxAdvertisedBandwidth limit if authorities are ever measured. See #28598, #28588.)

It seems like B is the easiest option, so I'm putting this ticket in the DirAuth component.

Last edited 9 months ago by teor (previous) (diff)

comment:2 in reply to:  1 Changed 9 months ago by arma

Replying to teor:

Therefore, each time every client makes a circuit, this many clients will choose an authority:

20*10*2000000/58103330 = 6.9

(Authorities are only chosen as middle nodes, because they don't have any other relevant flags.)

Actually, it's even lower than that. Only one of the 10 (dizum) has the Fast flag. So the others will be ignored by most clients.

So I'm not sure this is a big problem. It probably doesn't deserve much effort from us.

Agreed.

comment:3 Changed 9 months ago by wagon

So I'm not sure this is a big problem.

You know it better than me. I created this ticket only because you suggested it.

Authorities are only chosen as middle nodes, because they don't have any other relevant flags.

What forbids DA to become guard? As I know, usual fast relay with big uptime doesn't have an option to continue to be just a middleman, i.e., to not get guard flag.

Only one of the 10 (dizum) has the Fast flag. So the others will be ignored by most clients.

Good point. As I remember, nodes without Fast flag are not used for data transfer. Do you mean there can be some old clients which behaves differently?

comment:4 in reply to:  3 Changed 9 months ago by teor

Replying to wagon:

Authorities are only chosen as middle nodes, because they don't have any other relevant flags.

What forbids DA to become guard? As I know, usual fast relay with big uptime doesn't have an option to continue to be just a middleman, i.e., to not get guard flag.

They don't have the Guard flag.

Only one of the 10 (dizum) has the Fast flag. So the others will be ignored by most clients.

Good point. As I remember, nodes without Fast flag are not used for data transfer. Do you mean there can be some old clients which behaves differently?

Yes, and some custom clients, and some clients that are configured differently.

comment:5 in reply to:  3 Changed 9 months ago by wagon

Replying to wagon:

What forbids DA to become guard?

I've recalled it. To earn Guard flag a node must have sufficiently high bandwidth. So, it seems low bandwidth value forbids authorities to become guards.

Note: See TracTickets for help on using tickets.