Hi Gary, thanks for the warm welcome. I am currently not performing any load-balancing between my different Tor relays or my physical/virtual servers. Having thought about it a bit, I can only see this make sense if you intend to offer .onion services. I don't. Maybe I missed something? I have some bare-metal servers that run multiple instances of Tor to provide multiple relays each and I have some virtual instances (KVM, VMWare) that run a single instance of Tor, providing one relay each. These are hosted at different providers all over the world (see simplified attached graphic). As each relay is measured by the Tor network individually, is reachable independently and is not "critical" to the rest of the network, I don't see how load-balancing them could give me or the users of Tor a sizable benefit - as long as I am not running any hidden services. If one relay goes down, there is already an automatic switch-over to a different relay in the network. If one relay is overloaded, this is also detected and (presumably) it will be used less in the future. What part do you intent to load-balance and to what outcome? Best Regards, Kristian Dec 12, 2021, 15:42 by tor-relays@lists.torproject.org:

Welcome to tor-relays, Kristian. It's nice to meet a fellow Tor Farmer. It sounds like you are fairly seasoned with quite an extensive deployment of Tor Relays.

Are you performing any loadbalancing with Tor Nodes or are they Individually, Distributed Tor Relays?

I have a Single Tor Relay comprised of a number of Tor Nodes. I'm always interested in knowledge sharing related to Tor Loadbalancing.

What are your thoughts on the Pros & Cons of dedicating resources to a Single, Loadbalanced Tor Relay vs Many, Unloadbalanced Tor Relays by a Tor Operator? Perhaps, a Hybrid approach?

I look forward to hear more of your Tor farming practices.

Respectfully,

Gary — This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged)

On Sunday, December 12, 2021, 1:31:09 AM PST, abuse--- via tor-relays <tor-relays@lists.torproject.org> wrote:

Hello Tor relay operators,

I joined this mail list recently and wanted to take the opportunity to shortly introduce myself. My name is Kristian, I am based in Europe, and I operate all nodes behind the domain lokodlare.com. “Lökodlare” is Swedish for “onion farmers”, which is pretty much what I do.

My goal is to contribute to the Tor network by providing a couple of high-bandwidth nodes all over the globe, preferably at less common providers and/or in niche countries. I will focus on Middle and Guard relays, though I will throw some exits into the mix every now and then with a very reduced exit policy.

I currently operate 90+ relays and bridges with a theoretical bandwidth capacity of roughly 25 Gbit/s. As a snapshot, those nodes handled around 280 TB of Tor-related traffic in the past 24 hours.

I am looking forward to talk/discuss with all of you in the future.

Thanks, have a great Sunday, Kristian _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

On Sun, Dec 12, 2021 at 03:42:12PM +0000, Gary C. New via tor-relays wrote:

I have a Single Tor Relay comprised of a number of Tor Nodes. I'm always interested in knowledge sharing related to Tor Loadbalancing. What are your thoughts on the Pros & Cons of dedicating resources to a Single, Loadbalanced Tor Relay vs Many, Unloadbalanced Tor Relays by a Tor Operator? Perhaps, a Hybrid approach?

Hi Gary, One of the big downsides to trying to create one "meta" relay out of many independent relays is that each independent relay will make and maintain its own TLS connections with other relays. So while running a fast Tor relay the normal way might end up with roughly one connection to each other relay in the network (which could already be many thousands of connections), doing it the way you describe could result in many times that number of open connections. And even if your local router and systems can handle that many open connections, you're increasing the load on every other relay by forcing them to handle more connections. There will also be more bandwidth use, since each separate TLS connection will use its own keepalive packets to try to stay connected in the face of firewall and NAT timeouts, and also to try to foil rudimentary netflow-based traffic analysis attacks. And because circuits are spread out over many TLS connections, they won't get the privacy protections from being all bundled on a single TLS connection, i.e. a network observer will have an easier time distinguishing which circuit a given cell is for. Which relays are you running in this way? How do you aggregate all of the statistics/etc into a central Tor that publishes a unified relay descriptor? I would expect your meta-relay to have some kind of bizarre breakage, so we should check it out and see if that's true in practice. Thanks, --Roger

Roger, For completeness, I should amend point #3 to include configuring the Loadbalancer's Timeout to a Large Value: 3. Loadbalance using IP Transparency Mode (This was discovered while tirelessly combing through mountains of Tor debug logs), use Sticky Sessions based on Source IP Addresses, and configure Timeout to a Large Value (e.g., 5 minutes or 300 seconds) to allow the Tor instances to detect and deal with any overload state themselves (not the Loadbalancer) Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged) On Tuesday, December 14, 2021, 7:38:52 AM PST, Gary C. New <garycnew@yahoo.com> wrote: Hi Roger, I've found the secret to effectively loadbalancing Tor Relay Nodes is as follows: 1. Use the same version of Tor on all Upstream Servers 2. Start/Stop all Upstream Tor Nodes at the same time to keep in sync 3. Loadbalance using IP Transparency Mode (This was discovered while tirelessly combing through mountains of Tor debug logs) and use Sticky Sessions based on Source IP Addresses 4. Configure Upstream Tor Nodes to deliver return packets to the Loadbalancer 5. Configure all Upstream Tor Nodes to use the same DirAuthority and FallbackDir (This is how centralization of statistics is addressed) This configuration has been working well for the past six months. The only dow downsides that I've seen are if an Upstream Tor Node goes down, I have to leave it down or restart all the Upstream Tor Nodes to keep in sync. Occasionally, if a medium-term key is updated, I can see circuits migrate to a single Upstream Tor Node; however, that can be easily discerned and addressed by reviewing centralized syslogs and copying the updated .tordb directory to the other Upstream Tor Nodes with a synced restart. In terms of metrics, the written/read bytes per second is only reported for a single Upstream Tor Node, but that's not a big deal. It would be helpful if metrics were pulled remotely instead pushed. Please provide your email address and I'll be happy to message you directly with the name of my Tor Meta Relay. Respectfully, Gary— This Message Originated by the Sun. iBigBlue 63W Solar Array (~12 Hour Charge) + 2 x Charmast 26800mAh Power Banks = iPhone XS Max 512GB (~2 Weeks Charged) On Tuesday, December 14, 2021, 3:39:44 AM PST, Roger Dingledine <arma@torproject.org> wrote: On Sun, Dec 12, 2021 at 03:42:12PM +0000, Gary C. New via tor-relays wrote:

I have a Single Tor Relay comprised of a number of Tor Nodes. I'm always interested in knowledge sharing related to Tor Loadbalancing. What are your thoughts on the Pros & Cons of dedicating resources to a Single, Loadbalanced Tor Relay vs Many, Unloadbalanced Tor Relays by a Tor Operator? Perhaps, a Hybrid approach?

Hi Gary, One of the big downsides to trying to create one "meta" relay out of many independent relays is that each independent relay will make and maintain its own TLS connections with other relays. So while running a fast Tor relay the normal way might end up with roughly one connection to each other relay in the network (which could already be many thousands of connections), doing it the way you describe could result in many times that number of open connections. And even if your local router and systems can handle that many open connections, you're increasing the load on every other relay by forcing them to handle more connections. There will also be more bandwidth use, since each separate TLS connection will use its own keepalive packets to try to stay connected in the face of firewall and NAT timeouts, and also to try to foil rudimentary netflow-based traffic analysis attacks. And because circuits are spread out over many TLS connections, they won't get the privacy protections from being all bundled on a single TLS connection, i.e. a network observer will have an easier time distinguishing which circuit a given cell is for. Which relays are you running in this way? How do you aggregate all of the statistics/etc into a central Tor that publishes a unified relay descriptor? I would expect your meta-relay to have some kind of bizarre breakage, so we should check it out and see if that's true in practice. Thanks, --Roger _______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays