Hi,

thanks for reporting this issue. Replying inline:

Neel Chauhan:

Hi,

I believe the Tor bandwidth scanner nicknamed "longclaw" is measuring relays in the US West Coast worse than other bandwidth scanners in North America. This happens on multiple ISPs, both ones I have and ones I don't.

Tor bandwidth scanners and directory authorities not necessarily run in the same machine/IP and it's the case of longclaw's bandwidth scanner, which is located in the US East Coast.

This includes two Tor exit instances on a dedicated server hosted in Los Angeles on Psychz Networks (AS40676):

https://metrics.torproject.org/rs.html#details/156AAC3FAD1ACC8906316519DCB44...

https://metrics.torproject.org/rs.html#details/A69CEB30328B1E85C6B167FECAF2F...

And two Tor non-exit instances on a home server in Seattle on Wave Broadband (AS11404), using a symmetrical Gigabit link:

https://metrics.torproject.org/rs.html#details/B0F9BA27944FA59E3B1A182208FF7...

https://metrics.torproject.org/rs.html#details/DB710B14D7329B7289CFCC547F48E...

The consensus weight values from longclaw are much lower than other North American bandwidth scanners, according to https://consensus-health.torproject.org/.

This also affects other relays/ISPs on the West Coast US/Canada, such as Emerald Onion, AT&T U-verse, Sonic.net, and QuadraNet. The same ISPs/hosts in the East Coast aren't affected.

This discrepancy in the measurement disproportionately favors European and East Coast US/Canada relays at the expense of West Coast relays, centralizing the Tor network even further than it already was. This wasn't an issue in the past, even as early as a few months ago. It only started appearing around June.

If the reason for lower bandwidth measurements is the location -it could be other reasons- then it's weird that it would affect the US West Coast and not Europe, given it's located in the US East Coast.

To understand why this is happening, it's very helpful that you give us this information. I personally suspect it might not be related to the scanner location. We'll investigate this as part of the issue you opened at https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/40014.

It might take some weeks, since a lot of the work done on this topic is volunteer work. Apologies in advance about it.

Is anyone else hosting West Coast relays having this issue?

Good question.

Is

"longclaw" actually measuring bandwidth from Europe? If so, WHY?

No, it's not measuring bandwidth from Europe.

I got in contact with "longclaw"'s admin and he wasn't too helpful.

It looks to me that the longclaw's admin has been helpful if they have suggested you to write to this mailing list, so that more people can check this issue and/or they have suggested you to report an issue in gitlab so that the bandwidth scanner developers won't forget about it :)

Also, not all directory authorities run bandwidth scanners and not all of them know about the complexity on how bandwidth is determined.

Hope it helps.

Best, juga

Hi,

Am 16.08.2020 um 02:41 schrieb Neel Chauhan:

Hi,

I believe the Tor bandwidth scanner nicknamed "longclaw" is measuring relays in the US West Coast worse than other bandwidth scanners in North America. This happens on multiple ISPs, both ones I have and ones I don't.

The plots below can be a coincidence, but it shows at least there are more parameters for unexpected observations:

The consensus of a relay in Germany shows:

moria1 Fast Guard !HSDir Run Stab V2Dir Valid bw=17700 tor26 Fast Guard HSDir Run Stab V2Dir Valid dizum Fast Guard HSDir Run Stab V2Dir Valid gabel. Fast Guard HSDir Run Stab V2Dir Valid bw=21800 danne. Fast Guard HSDir Run Stab V2Dir Valid maatu. Fast Guard HSDir Run Stab V2Dir Valid bw=24000 farav. Fast Guard HSDir Run Stab V2Dir Valid bw=21500 longc. Fast !Guard HSDir Run Stab V2Dir Valid bw=1800 bastet Fast Guard HSDir Run Stab V2Dir Valid bw=17300

The mtr plot for the same server shows the hop "100ge1-1.core1.par2.he.net" is generating many packets losses. Where "100ge14-1.core1.nyc4.he.net" puts milli seconds into the game:

Packets Pings Host Loss% Snt Last Avg Best Wrst StDev 1. 91-143-90-251.gw.dsw-c6ka.as35366.net 0.0% 51 0.3 1.4 0.3 46.3 6.4 2. po162.bbsw-h3-j1cr.as35366.net 0.0% 51 0.5 0.9 0.3 9.3 1.4 3. po150.bbsw-h2-j1a.as35366.net 0.0% 51 0.4 4.5 0.3 189.5 26.4 4. po205.bbsw-h4a-fra.as35366.net 0.0% 51 7.3 7.6 7.0 24.4 2.4 5. 10gigabitethernet2-3.core1.fra1.he.net 0.0% 50 9.0 11.1 7.1 32.6 6.8 6. 100ge16-2.core1.fra1.he.net 0.0% 50 7.7 7.6 7.3 13.9 0.9 7. 100ge1-1.core1.par2.he.net 51.0% 50 17.0 20.2 16.7 39.2 6.6 8. 100ge14-1.core1.nyc4.he.net 0.0% 50 87.1 90.1 87.1 102.7 4.3 9. 100ge10-1.core1.ymq1.he.net 0.0% 50 99.4 101.3 99.2 109.7 3.2 10. estruxture-data-centers.10gigabitethernet1-1-40.switch3.ymq1.he.net 0.0% 50 99.3 101.0 99.1 136.5 6.2 11. 64.15.69.54 0.0% 50 98.2 98.1 97.8 99.0 0.2 12. anon.riseup.net 0.0% 50 98.4 98.4 98.0 100.3 0.5

Relays at other hosting locations choose for different routes and longclaw sees them perfectly equal. It*s a case by case.

-- Cheers, Felix