Re: [tor-relays] bwauths don't like one of my relays?
Hi, Thanks for reporting this issue, and sorry it's taken us a while to get back to you. Many of us have been on leave over the holidays, and we're still catching up. > On 4 Jan 2020, at 10:18, trusting.mcnu...@protonmail.com wrote: > > An update on my relay 'kima' ($54A35E582F9E178542ECCFA48DBE14F401729969) -- > > Eventually I did get assigned more weight; the relay is currently at 4600. > > Along the way I think I discovered one potential problem with the bwauth > bootstrapping process, at least for sbws. (I'm not sure about torflow.) Torflow's partitions have a similar issue, but it's actually worse: a relay can get stuck in a low-bandwidth partition forever. > When sbws is constructing a two-hop measurement circuit to run a test, it > tries to pick an exit that has at least twice the consensus weight of the > current relay-under-test: > https://github.com/torproject/sbws/blob/master/sbws/core/scanner.py#L216 > > So this means that in this case, sbws would have picked any exit that was not > a BadExit, has an acceptable ExitPolicy, and has a consensus weight of at > least, well, 2. That's not a lot. > > As it turns out, something like 10% of exits have under a 600Kbyte/sec > advertised bandwidth. So it seems pretty easy from this weight=1 bootstrap > scenario to get paired with an exit that will give poor test results. > > Perhaps bwauth path selection should also choose a testing pair from > exits/relays with a certain absolute minimum of weight or advertised > bandwidth? I've opened a ticket for this issue: https://trac.torproject.org/projects/tor/ticket/33009 We'll try to resolve it before we deploy any more sbws instances. T signature.asc Description: Message signed with OpenPGP ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] TCP CCA for Tor Relays (and especially Bridges)
Quoting Iain Learmonth (2020-01-20 16:00:01) > Last time I looked you could not switch TCP congestion control algorithm > in Linux per-namespace (maybe you can now and you don't need to have > multiple VMs). It's been allowed for about two years now [0], but you don't need it anyways. Trying out new congestion control algorithms is not exactly a new fad, so it has been possible to set the congestion control algorithm via setsockopt since, apparently, Linux 2.6.13 [1], released a good 15 years ago. You'd probably need to patch tor to do that effectively, but if you're going to all this trouble anyways, patching one program shouldn't really be a barrier. [0] https://github.com/torvalds/linux/commit/6670e152447732ba90626f36dfc015a13fbf150e [1] http://man7.org/linux/man-pages/man7/tcp.7.html ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] TCP CCA for Tor Relays (and especially Bridges)
Hi, On 11/01/2020 05:07, Matt Corallo wrote: > Sadly, the large scale deployments of BBR are mostly not high-latency links > (as CDNs generally have a nearby datacenter for you to communicate with), and > the high retransmission rates may result in more “lag” for browsing when > absolute bandwidth isn’t the primary concern. On the flip side, Spotify’s > measurements seem to indicate that, at least in some cases, the jitter can > decrease enough to be noticeable for users. BBR is good for Netflix, but is not so good for non-streaming traffic. You also get issues between competing flows which doesn't matter for Netflix (typically you only watch one video at a time) but would matter for Tor. We don't have good models of what Tor traffic looks like, but I strongly suspect it is different to the Neflix/YouTube typical workloads. > Is there a way we could do measurements of packet loss/latency profiles of > bridge users? This should enable simulation for things like this, but it > sounds like there’s no good existing work in this domain? We have two tools that build simulated/emulated Tor networks: chutney and shadow. Unfortunately, neither implements everything that would be required. We really want to see what happens when x% of the network switches congestion control algorithm and see how flows interact at large relays (either relay to relay, or guard connections). If you have a large openstack cluster available, you could set up with your favorite orchestration tool a number of VMs with emulated WAN links between them, and connect a bunch of Tor clients to that network in other VMs, and perform measurements. Last time I looked you could not switch TCP congestion control algorithm in Linux per-namespace (maybe you can now and you don't need to have multiple VMs). Generally I would recommend *not* changing from TCP cubic unless you really understand the interactions that are going on between flows. Thanks, Iain. signature.asc Description: OpenPGP digital signature ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo-Information-Sharing-Specification updates and final comments until 2020-02-02
Hi, > On 20 Jan 2020, at 17:43, Georg Koppen wrote: > > nusenu: >> Georg Koppen: >>> Yes, that's what I figured. So, it seems to me not all your proposed >>> keys are equally important (e.g. your require the email one). Which of >>> those (or maybe even which cluster of those) are/is important enough in >>> your opinion to could be considered on topic for a potential tor >>> proposal? (If we would go that route) >> email (if a fully automated verification process is included) > > Okay, that sounds like a promising start. > The only negative point of removing the ContactInfo field altogether is loosing information that people put into it. >>> Well, it does not necessarily mean losing information as the field would >>> not just go away but be replaced by other, more narrowed down ones. >> which seems to imply a configuration change and not all operators will >> change their configuration > > That might be true but we'd have some clear process ahead to phase the > old field out and transition to the newer ones, and transparent ways to > enforce the new model after some time. > > I feel that's a big plus to an optional spec that kind of exists in > parallel to the status quo and might play somehow a role in determining > whether a relay might get bumped out of the network or not etc. If we want to recommend that operators provide an email address to stay in the consensus, we should make it easy for operators to provide an email. If we have a preferred format, we should automatically provide the email in that format. Here's a rough sketch of a spec that could work: * add a ContactEmail field to the torrc and descriptors. The field must be encoded as UTF-8. (See proposal 285 [0].) * do some minimal validation on the email field, that makes sure it looks like an email address. (Or don't, so operators can obfuscate their addresses from spammers.) And then there's a few different transition options, some of which overlap: 0. Do nothing. 1. Combine ContactEmail and ContactInfo in the descriptor's ContactInfo field, in the format that the ContactInfo spec recommends. If the email is already a substring of ContactInfo: 1.1. Do nothing. 1.2. Make sure the ContactInfo email is in the format that the ContactInfo spec recommends. 1.3. Remove the email (and the ContactInfo spec email field name) from the ContactInfo field in the descriptor, and just put it in the ContactEmail field. We could wait a few releases to make this breaking change. 2. Warn if the ContactEmail field isn't set on a relay. 3. Reject the configuration if the ContactEmail field isn't set on a relay, after a few releases. 4. Rename ContactInfo to OtherContactInfo, but allow ContactInfo as an alias for a few releases. 5. Deprecate the ContactInfo field in descriptors, and replace it with the email and other contact info fields, after distributing them in parallel for a few releases. Here's my opinion: I'd prefer no validation, combining the fields, and ensuring the email is in the ContactInfo spec format. I think we should give a config warning if the email is missing. Eventually, we should probably stop duplicating email in the ContactInfo and ContactEmail fields. (Although compression helps mitigate the impact of this kind of duplication.) I don't think we should rename ContactInfo. It is one way to force operators to eventually modify their torrc. But if we want to force a config change, let's just require that ContactEmail is set. I don't think renaming or deprecating ContactInfo in the descriptor is useful. (Renaming a field breaks a bunch of tools for no good reason. And people clearly like having an unstructured or extensible field.) But that's all just my opinion. I've run relays, and made changes to tor, but I don't work with this data every day. (Occasionally, I use it as part of selecting fallback directory mirrors.) Any proposed Tor changes should be guided by people who deal with this data all the time: the network health, bad relays, and metrics teams. (And the network team, to help with the design and implementation in Tor.) T [0]: https://gitweb.torproject.org/torspec.git/tree/proposals/285-utf-8.txt T -- teor -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
