Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#13822 closed enhancement (implemented)

Raise ROUTER_REQUIRED_MIN_BANDWIDTH

Reported by: arma Owned by:
Priority: Medium Milestone: Tor: 0.2.6.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-relay, tor-bridge
Cc: karsten, isis Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

or.h:#define ROUTER_REQUIRED_MIN_BANDWIDTH (20*1024)

But we raised the recommended minimum listed on the website to 100KB, and then again recently to 250KB.

Now, we should be aware that this #define is used for both relays and bridges. But a tiny bridge is increasingly looking like it will drag down users who use it. But we also don't want to skew the incentives so a 100KB/s bridge sets her BandwidthRate to 250KB so her bridge can start.

In any case, I think raising from 20 to 100 is an easy and wise step. We should discuss whether raising to 250 is wise too.

Child Tickets

Attachments (1)

bandwidth-rates-2015-02-04.png (46.2 KB) - added by karsten 5 years ago.
Bandwidth rates of bridges and relays in January 2015

Download all attachments as: .zip

Change History (18)

comment:1 Changed 5 years ago by nickm

I have no objection to either change in principle, but first could we answer how much of the network we'd lose either way?

comment:2 Changed 5 years ago by arma

Cc: karsten added

Okeydoke -- I am cc'ing our friendly metrics man. Karsten, please draw others in as you see fit.

I think another question is how many of these tiny relays have the Fast flag -- I'd guess very few of them.

That's actually an interesting interaction: if we encourage the tiny relays to disappear (I actually guess that some of them will raise their bandwidthrate in response, but you're right that some of them will disappear), then the bottom 1/8th of the relays becomes faster, thus making the Fast flag more competitive at the low end. I think this is a fine step.

Karsten, can you take a quick look at bridge bandwidthrates too? Another option is to break this check into two cases -- minimum 250KB/s for public relays, and minimum 100KB/s for bridges.

(There's also another edge case here where somebody could set a bandwidthrate of 80KB and a bandwidthburst of 10GB, and they're very likely a perfectly helpful relay yet we'd be forcing them to change. I think I'm ok with that.)

(Yet another option is to have a lower threshold for relays whose exit policy would earn them the Exit flag. I don't currently have reason to believe that added complexity would be worth it.)

And for context, see also all the discussion on #1854.

comment:3 Changed 5 years ago by nickm

karsten, ping? I'm happy to change these numbers once I hear what the new values should be.

comment:4 Changed 5 years ago by nickm

Status: newneeds_information

comment:5 Changed 5 years ago by karsten

Oops, I totally missed this one until Nick's ping on IRC. I'll take a look in the next couple of days. Sorry for the delay.

Changed 5 years ago by karsten

Bandwidth rates of bridges and relays in January 2015

comment:6 Changed 5 years ago by karsten

Here's a graph of bandwidth rates published by relays and bridges in their server descriptors in January 2015. Looks like raising the threshold to 100 KiB/s would kick out over 20% of bridges and 8% of relays (the lower end of that vertical blue line, assuming that having exactly 100 KiB/s would be sufficient to stay in the network). A threshold of 250 KiB/s would equally kick out around 25% of bridges and almost 25% of relays. A threshold of 50 KiB/s would keep most bridges and relays in the network.

comment:7 Changed 5 years ago by nickm

Okay, so 250 is definitely too high. What do we think of choosing 50 vs 75 vs 100? And can we have separate minima for relays and bridges?

comment:8 Changed 5 years ago by nickm

Status: needs_informationneeds_review

See feature_13822 in my public repository. It splits the relay minimum from bridge minimum, and picks conservative values for the new minima.

comment:9 in reply to:  6 ; Changed 5 years ago by isis

Replying to karsten:

Here's a graph of bandwidth rates published by relays and bridges in their server descriptors in January 2015. Looks like raising the threshold to 100 KiB/s would kick out over 20% of bridges and 8% of relays (the lower end of that vertical blue line, assuming that having exactly 100 KiB/s would be sufficient to stay in the network). A threshold of 250 KiB/s would equally kick out around 25% of bridges and almost 25% of relays. A threshold of 50 KiB/s would keep most bridges and relays in the network.


Huh… somehow my numbers are way different… which bandwidth number from the server-descriptors are you using?

I made a Python script which generates an ExcludeNodes line for relays whose bandwidth (as reported in either cached-consensus or cached-microdescriptor-consensus) is below N KB/s. This is the number of relays it gives for 100 KB/s and 250 KB/s, respectively:

∃!isisⒶwintermute:(master *=)~/code/scripts ∴ sudo -u tor ./exclude-slow-tor-relays -d /home/isis/.tor/data -b 100
Excluding 2563/6972 relays with bandwidth <= 100 KB/s.
∃!isisⒶwintermute:(master *=)~/code/scripts ∴ sudo -u tor ./exclude-slow-tor-relays -d /home/isis/.tor/data -b 250
Excluding 3259/6972 relays with bandwidth <= 250 KB/s.

So we should lose 36.76% of relays in the 100 KB/s case and 46.74% in the 250 KB/s case.

comment:10 Changed 5 years ago by isis

Cc: isis added
Keywords: tor-bridge added

comment:11 in reply to:  9 ; Changed 5 years ago by arma

Replying to isis:

Huh… somehow my numbers are way different… which bandwidth number from the server-descriptors are you using?

Karsten is looking at the advertised rate limits in the descriptors. That's what ROUTER_REQUIRED_MIN_BANDWIDTH refers to -- it prevents you from starting your relay if you are rate limiting it so thoroughly that it will never be of any use to anybody.

(You are looking at consensus weights, which is a different thing.)

comment:12 Changed 5 years ago by karsten

Actually, I'm looking at bandwidth rates (the first bandwidth number), not advertised bandwidths (the minimum of the three bandwidth numbers). That's how I understood the question. I can re-run with advertised bandwidths if desired.

comment:13 Changed 5 years ago by nickm

Has anyone had a chance to look at this code?

comment:14 in reply to:  11 ; Changed 5 years ago by isis

Replying to arma:

Replying to isis:

Huh… somehow my numbers are way different… which bandwidth number from the server-descriptors are you using?

Karsten is looking at the advertised rate limits in the descriptors. That's what ROUTER_REQUIRED_MIN_BANDWIDTH refers to -- it prevents you from starting your relay if you are rate limiting it so thoroughly that it will never be of any use to anybody.

(You are looking at consensus weights, which is a different thing.)

Got it, thanks! Sorry for the distraction.

Should I make a different ticket for DirAuths to do some calculation like "If the relay has been measured, and it's been around for X months, and its measured bandwidth is below N KB/s, then do not include it in the consensus"? Sort of like raising the cutoff ratio for the Fast flag, but rather, relays which are so slow that distributing their descriptors costs more bandwidth than those relays provide, rather than merely not getting the Fast flag, wouldn't be distributed at all.

comment:15 in reply to:  8 Changed 5 years ago by yawning

Replying to nickm:

See feature_13822 in my public repository. It splits the relay minimum from bridge minimum, and picks conservative values for the new minima.

Assuming the arguing over the constants is complete, the changes look good to me. If the arguing over the constants is still in progress, then 2 #defines need to be changed but the rest of the code looks good to me.

comment:16 Changed 5 years ago by nickm

Resolution: implemented
Status: needs_reviewclosed

Okay, and thanks for the review! The constants are:

#define RELAY_REQUIRED_MIN_BANDWIDTH (75*1024)
#define BRIDGE_REQUIRED_MIN_BANDWIDTH (50*1024)

I am merging this patch. Please let me know if the constants need updating RSN.

comment:17 in reply to:  14 Changed 5 years ago by arma

Replying to isis:

Should I make a different ticket for DirAuths to do some calculation like "If the relay has been measured, and it's been around for X months, and its measured bandwidth is below N KB/s, then do not include it in the consensus"? Sort of like raising the cutoff ratio for the Fast flag, but rather, relays which are so slow that distributing their descriptors costs more bandwidth than those relays provide, rather than merely not getting the Fast flag, wouldn't be distributed at all.

If our bwauths were better, I think this would be a good idea. But right now our bwauths are outputting really crazy numbers for relays, or no numbers at all, so imo the benefit of having the relays in the consensus, for debugging (and for comfort of the relay operator), outweighs the cost of the directory overhead.

I guess more broadly you could argue for not including the relays that don't have the Fast flag, "since nobody would use them anyway". Hm! :)

Note: See TracTickets for help on using tickets.