Hi, Roger Dingledine wrote: > On Wed, Jul 24, 2019 at 07:36:59PM +0300, s7r wrote: >> I'd like to know more details about how exactly the bridge bandwidth >> authority works, and if we use the "weight" of each bridge for anything. > > I'll start off by answering some of the questions, and let others > fill in the gaps. > > The first answer is that there is no such thing as a bridge bandwidth > authority. There is only the bridge directory authority, Serge, which > collects self-signed bridge descriptors from bridges, checks reachability, > and passes them on to the bridgedb service. Thanks for the answer. Well, this pretty much addresses all my concerns. And it all makes sense now. > >> For example, I have setup 5 obfs4 bridges, with the exact very same >> hardware resources and all on the same network speed of course. > > Thanks! > >> One of them gets used by clients (say 20-50 unique clients every 6 hours >> or so) while the rest of 4 are not used at all. This usage is not a >> concern for me, as its known bridges take time until they get used, >> depending on which bucket they have been assigned and etc. So I assume >> it's OK at this particular point in their lifetime to be unused by any >> client. > > Yep, it is not unusual for bridges to not see much use. As you say this > is due to a variety of factors -- which distribution strategy bridgedb > picks for them, which countries are blocking Tor in what way this week, > whether your IP address has gotten on any blacklists, etc. > >> But what I am curious about is, when I search them on RelaySearch, the >> used one has a measured bandwidth of over 2 MiB/s (and has the fast >> flag) while other 3 unused ones have bandwidths of between 50 and 60 >> KiB/s (these also have the fast flag) and there is one last one which is >> also not used and has a bandwidth of less than 10 KiB/s that does not >> have the fast flag. (Fast flag missing is also not my problem, I am just >> mentioning it as a side detail). >> >> Now I know for sure those values are not at all in according to the real >> environment. Each bridge should be at least capable of 3 MiB/s even if >> all 5 are used at the same time at their full speeds. Actually I have >> simulated this, it's not just theoretical. >> >> Is there anything related to usage, so that the bridge bandwidth >> authority only measures the used bridges? What could have cause such big >> discrepancy in my particular case, any ideas? > > These numbers are simply the self-reported bandwidth numbers from the > bridges. > > All kinds of relays, including bridge relays, watch how much traffic > they've seen themselves doing, and put the largest burst they've seen > into their relay descriptor (or bridge descriptor in this case). > > https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n432 > > So the bridges that have a bunch of users have had more traffic load, > and thus have a higher burst traffic number to report. > > Or to answer it differently, the issue is the other way around from > what you were worried about: it isn't that something is giving one of > your bridges a higher bandwidth value, and thus it has more users. It's > that one of your bridges has more users, so it ends up with a higher > bandwidth value. Of course, the more clients they have it means the bigger burst they see in their bandwidth, and use it to build the bridge descriptor. That is just passed on to birdgedb and reported / used exactly as it is, given there's no bridge bandwidth authority. > >> Also, do we use the weight of each bridge in order to determine how much >> % probability it has to be served to a request in the bucket that is >> part of, or we don't use bridge weights for anything at all? > > I believe we don't use bridge weights for anything at all. Yes, it makes sense we don't use bridge weights for anything at all because we do not have accurate bridge weights since we don't measure them with anything that is outside the control of the bridge operator. We only have what bridges report, which can be of course gamed by the bridge operator trivially. One bandwidth authority would not be sufficient anyways, for the bridges, so it can get quite complicated to measure them accurately for no obvious benefit if we consider how we distribute the bridges currently. This would be a risk if it could happen to the Guards in the consensus for example (but it can't, of course), because those are sampled by all regular clients. Bridge clients have to do some manual out-of-band action to get the bridge data, so gaming the "weight" of a bridge doesn't actually influence anything, as long as we maintain our distribution strategy and randomly assigning bridges to certain buckets regardless of their _reported_ speed. > > But I might be wrong about this last part. We've changed our mind several > times over the years about how to handle weighting. Specifically, > I don't know if the behavior changed with the latest iteration of the > entry guard selection design: > https://gitweb.torproject.org/torspec.git/tree/guard-spec.txt > > Hope that helps, > --Roger
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays