Tor bandwidth scanner "longclaw" slow to the US West Coast
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. 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. Is anyone else hosting West Coast relays having this issue? Is "longclaw" actually measuring bandwidth from Europe? If so, WHY? I got in contact with "longclaw"'s admin and he wasn't too helpful. Best, Neel Chauhan === https://www.neelc.org/
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 -- they/them http://zkaan2xfbuxia2wpf7ofnkbz6r5zdbbvxbunvp5g2iebopbfc4iqmbad.onion/vks/v1...
Hi juga, Sorry for the delayed response. On 2020-08-18 10:05, juga wrote:
thanks for reporting this issue. Replying inline:
No problem.
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.
Good to know.
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.
Thanks for telling me. It seems weird, West Coast congestion maybe?
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.
Understood. I don't mind helping if you need help. I am a Core Tor contributor, but am also open to working with sbws.
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.
Good to hear.
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.
I guess it's really easy to complain and blame longclaw's admin. It could also be peering, but I am not sure. Wave does have congestion issues from time to time, but this affects more than Tor. Sometimes, faravahar also may have this issue, but not to the same extent, and I can't confirm if this is true. Thank you for responding.
Best, juga
-Neel
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
Not sure if my relay is similar, but I've been seeing a slow fall in consensus weight and advertised bandwidth over the past few months even though absolutely nothing has changed at my end. Well, apart from me *increasing* the RelayBandwidth settings. Also before I shut my relay down for a couple of weeks late last year, it had, and maintained guard status for about 6 months. Now it yo-yos in and out of guard on a regular basis. https://metrics.torproject.org/rs.html#details/D195E5CE8AE77BAC91673E6CFB7BD... Cheers. On 8/15/2020 5:41 PM, Neel Chauhan wrote:
Hi,
Is anyone else hosting West Coast relays having this issue? Is "longclaw" actually measuring bandwidth from Europe? If so, WHY?
participants (4)
-
Eddie -
Felix -
juga -
Neel Chauhan