- tor-relays - lists.torproject.org

BWauth no-consensus state in effect
by starlight.2015q2＠binnacle.cx 06 Aug '15

06 Aug '15

FYI list https://trac.torproject.org/projects/tor/ticket/16696 Description At present both 'longclaw' and 'maatuska' have dropped out of the BW consensus ('longclaw' is restarting with new version, not sure about 'maatuska'). This has caused the BW consensus logic to revert to using relay self-measurement for BW weightings due to fewer than three BW authorities participating. The 10000 cap placed on self-measure values is causing super-fast relays serious demotion and slower relays corresponding promotion in the consensus weighting. Possibly this may result in network unbalance issues. Some adjustment of the logic seems in order.

10 12

Blutmagie does not see 0.2.7.2 bandwidth
by starlight.2015q3＠binnacle.cx 05 Aug '15

05 Aug '15

>At Tue Aug 4 11:22:22 UTC 2015 by Olaf Selke olaf DOT selke at blutmagie DOT de > >by the way... I will probably shut down blutmagie >tor network status in September this year cause >the data center has terminated the contract >housing my servers 10/31/15. Could you make your modified Torstatus code available on https://gitweb.torproject.org/torstatus so that someone else can set up another like it? Blutmagie appears to have significant and desirable enhancements to the code presently in the GIT repository. I might contribute a new Torstatus, but if not me someone surely will.

2 1

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 05 Aug '15

05 Aug '15

Maybe geo-location would not be so great because two networks in the same physical area might have relatively poor connectivity to each other. Aggregated IP block might be the ticket. CIDR-Report has both actual and suggested netblock aggregations. http://www.cidr-report.org/as2.0/#Gains Shows 562259 reduced to 253420 advertisements. Perhaps too fine-grained, but 250k is not so much bigger than the 45k ASN count. Idea is to anchor metrics to maximum size BGP routable blocks, which ought to correlate performance-wise down to all the IPs in each block. >>BWauths are continuously pairing relays for >>measurements, and perhaps metrics from that >>could be mapped to autonomous system numbers > >. . .scratch AS, geo-location is >better and MaxMind specializes in that > >Pinging a FiOS relay in LA takes >75ms while a close-by relay takes >8ms. Both are in AS 701.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 05 Aug '15

05 Aug '15

>BWauths are continuously pairing relays for >measurements, and perhaps metrics from that >could be mapped to autonomous system numbers . . .scratch AS, geo-location is better and MaxMind specializes in that Pinging a FiOS relay in LA takes 75ms while a close-by relay takes 8ms. Both are in AS 701.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

At Tue Aug 4 22:17:54 UTC 2015 by Mike Perry mikeperry at torproject dot org > >In some instances where I have not selected >my guards manually, Tor Browser is unbearably >slow. Like really, really painfully slow. >The whole time. Until I reinstall it. > >This makes me think that the performance of >people who pick guards from the tail is much >much worse than the performance of the top >guards, and this property likely is acting as >a deterrent to adoption. > Perhaps the guard-selection algorithm could be enhanced to consider some sort of distance/reachability metric generated by BWauths? BWauths are continuously pairing relays for measurements, and perhaps metrics from that could be mapped to autonomous system numbers (from MaxMind) in a useful way without requiring tremendous effort? Matrix analysis comes to mind. If one's guard is on the other side of the world, network latency and random congestion will hurt. I've read some path selection research is under way with an eye toward reducing passive traffic correlation exposure--this seems like it would help performance in a similar way.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

Many under-utilized and never-utilized exits relays back online with BWauth outage. Unscientific sample out of 234 previously Unmeasured=1 exit relays, but almost all of the ones checked are like these https://atlas.torproject.org/#details/0D7739DEF50470356744440435FED9E1F57EF… https://atlas.torproject.org/#details/1E014CF541F32F377A116E78B76A603B8346A… https://atlas.torproject.org/#details/2316E6F012ACA52FDB09C745B0F5B41E78C23… https://atlas.torproject.org/#details/2A63402166192D66018D3FCB1ED8DE740CE71… https://atlas.torproject.org/#details/37C49200E04C8FE70799430718B10CEA5DBFB… https://atlas.torproject.org/#details/47BDCB56A9CCDAAAA71D74549E388C8EA1265…

2 1

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

Poking around Blutmagie, I suspect the number of relays with chopped bandwidth weightings might be more like in the range of 25-45. Perhaps the PID-controller algorithm should be adjusted to bias somewhat less toward super-fast relays.

1 0

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

At Tue Aug 4 20:16:17 UTC 2015 by Jannis Wiese mail at janniswiese.com >Strange thing: My relay [0] is speeding up since then >significantly (finally!!) That's because with no BWauth quorum the consensus algorithm reverts to using self-measured bandwidth with a ceiling of 10000. This causes the weight super-fast relays to drop substantially and provides a corresponding boost to middle and slower relays. Also puts most of the 450 Unmeasured=1 relays back in the game. In addition, this state eliminates all the crazy-stupid-buggy behavior of the BWauths that has been vexing operators so much. Only losers are the folks with huge bandwidth + CPU + tweaking in their relays, but the drop is not all that terrible. I've been watching this for two-plus days now and the Tor network rather runs better this way. Looks like no more than 50-100 relays are in the category where the weight is cut substantially, and plenty of unused capacity exists in the other 3000 or useable relays to make up the difference. Unfortunately the BWauths will likely be back due to the problem of adversarial gaming of the self-measure values. Even with a cap of 10000 someone will figure out ways to abuse the old pre-2009 approach of balancing the network. One can only hope that enough of the bugs have been worked out that BWauths will be behaving better going forward.

1 0

Blutmagie does not see 0.2.7.2 bandwidth
by starlight.2015q2＠binnacle.cx 04 Aug '15

04 Aug '15

FYI list https: // torstatus DOT blutmagie DOT de is registering relays running 0.2.7.2 as having zero bandwidth. I believe this is because the write-history read-history lines in extra-info have moved from the top down to the middle of the document. Many super-fast relays running 0.2.7.2 are showing zero bandwidth and have dropped to the bottom of the ranking as a result. Might be a bug in 'metrics-db' or it might be a bug in a Blutmagie customization. Seems that the code at https://gitweb.torproject.org/torstatus.git/ retrieves advertised (self-measure) bandwidth rather than consumed bandwidth, so it's hard to say without a deep-dive into the code. I'm going by the fact that the new https://torstatus.rueckgr.at/index.php?SR=Bandwidth&SO=Desc shows advertised bandwidth and presumably runs code from the GIT repository. Sent an e-mail to Olaf Selke advising him of this issue. Not sure if he still maintains it, but the message did not bounce.

3 5

Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
by torrry＠Safe-mail.net 03 Aug '15

03 Aug '15

> debugging the old Blutmagie Perl scripts I found all routers like > splitDNA running Tor 0.2.7.2 sending two hash values in the > extra-info-digest. I suppose this isn't expected by the script parsing > the data. > > GETINFO desc/name/splitDNA > 250+desc/name/splitDNA= > router splitDNA 62.210.82.44 21 0 143 > [...] > extra-info-digest D6F7A98078BDA327D388D918EBA92D0FC9EDC487 > nMA7WhPSpQmquUdYpwIdQtdcKvTAcvNDnXleiPBia0U It shouldn't be expected by the script: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt ------------------------------------------------------------------ "extra-info-digest" digest NL [At most once] "Digest" is a hex-encoded digest (using upper-case characters) of the router's extra-info document, as signed in the router's extra-info (that is, not including the signature). (If this field is absent, the router is not uploading a corresponding extra-info document.) ------------------------------------------------------------------- Fetching descriptors via: http://<DIR_SERVER>/tor/server/all has 2 values for extra-info-digest as well.

1 0