Re: [tor-relays] TCP CCA for Tor Relays (and especially Bridges)

2020-01-12 Thread Matt Corallo 
Hmm, this type of test doesn’t really seem to have much connection to the 
average Tor user. Middle relay <-> middle relay connections may be mostly 
servers, but residential/mobile connections in Russia/Iran/China likely don’t 
perform quite the same. Worse still, BBR can have measurable effects on packet 
retransmissions, and while it may require an unrealistic amount of state to 
track such things for many flows, it’s not a given that it won’t make tor 
traffic stand out (luckily, of course, large CDNs like DropBox, Spotify, 
YouTube, etc have been migrating to it, so maybe this won’t be the case in the 
future).

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.

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?

Matt

> On Jan 10, 2020, at 17:36, Roman Mamedov  wrote:
> 
> On Fri, 10 Jan 2020 16:24:56 +
> Matt Corallo  wrote:
> 
>> Cool! What did your testing rig look like?
> 
> A few years ago I've got a dedicated server from one of these cheap French
> hosts, which appeared to have a congested uplink (low-ish upload speeds).
> Since the support was not able to solve this, but the server was very cheap to
> cancel just over that, I looked for ways to utilize it better even despite the
> congestion.
> 
> If I remember correctly, I also had a Japanese VPS at the time, so my tests
> were intentionally for a "difficult" case, uploading from France to Japan
> (with 250+ms ping).
> 
> Here are my completely unscientific scribbles of how all the various
> algorithms behaved. The scenario is uploading for a minute or so, observing
> the speed in MB/sec visually, then recording how it appeared to change during
> that minute (and then repeating this a couple of times to be certain).
> 
> tcp_bic.ko   -- 6...5...4
> tcp_highspeed.ko -- 2
> tcp_htcp.ko  -- 1.5...3...2
> tcp_hybla.ko -- 3...2...1
> tcp_illinois.ko  -- 6...7...10
> tcp_lp.ko-- 2...1
> tcp_scalable.ko  -- 5...4...3
> tcp_vegas.ko -- 2.5
> tcp_veno.ko  -- 2.5
> tcp_westwood.ko  -- <1
> tcp_yeah.ko  -- 2...5...6
> 
> This was on the 3.14 kernel which did not have BBR yet to compare. In later
> comparisons, as mentioned before, it is on par or better than Illinois.
> 
>> I suppose the real question is what does the latency/loss profile of the
>> average Tor (bridge) user look like?
> 
> I think the real question is, is there any reason to *not* use BBR or that
> Illinois. So far I do not see a single one.
> 
> -- 
> With respect,
> Roman

___
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)

2020-01-12 Thread Matt Corallo 
Cool! What did your testing rig look like?

I suppose the real question is what does the latency/loss profile of the
average Tor (bridge) user look like?

On 1/10/20 8:18 AM, Roman Mamedov wrote:
> On Thu, 9 Jan 2020 00:58:36 -0500
> Matt Corallo  wrote:
> 
>> BBA should handle random packet loss much better than, eg, Cubic.
> 
> Do you mean BBR? https://github.com/google/bbr
> 
> In my experience it does work very well on Tor relays, and also on servers in
> general (keeping in mind that these TCP congestion control algorithms only
> affect upload, so matter most on hosts which do a lot of uploading, or as in
> case of Tor both upload and download).
> 
> The next best in my tests was Illinois:
> https://en.wikipedia.org/wiki/TCP-Illinois I've been using it for a long time
> before BBR got included in the Linux kernel. Today, in some cases BBR is
> better, in other Illionis can be. The latter ramps up a bit slower on new
> connections, but appears to be able to achieve higher speeds after that.
> 
> These two are head and shoulders better than all other options available in
> the Linux kernel, including the default one (Cubic). And yes, perhaps indeed
> this is an area of Tor relay performance tuning that doesn't get enough of the
> attention that it deserves.
> 
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Re: [tor-relays] Introducing: The Onion Pack

2020-01-12 Thread John Ricketts 
Thank you Ralph!

On Jan 12, 2020, at 15:18, Ralph Wetzel  wrote:

?
Good evening,
I'd like to take the opportunity to introduce 'The Onion 
Pack', a Tor Relay Bundle for 
Windows.
Intended to lower the effort to setup a Tor relay (or bridge) on a Windows 
system to almost zero, it merges the latest versions of Tor's Windows Expert 
Bundle and The Onion 
Box into a smart relay / dashboard system, ready to run 
after some minutes of installation.
Neither the Windows Expert Bundle nor The Onion Box are firmly linked into the 
installer yet pulled on demand.
A tray icon acts as additional user interface, providing what is necessary to 
control the Tor node beyond the capabilities of The Onion Box.

Being aware that this is a tool most probably dedicated to first-timers I'd be 
happy to receive any kind of feedback.
Just give it a try!

Greetings, Ralph
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[tor-relays] Relay with odd behavior

2020-01-12 Thread Clément Février 
Hi,

I am running a tor relay on Ubuntu 18.04 in a LXD container. After
upgrading form tor version 0.4.2.5-1~bionic+1 over 0.4.1.6-1~bionic+1,
my relay is having an odd behavior.

My relay is running for 9 days and the number of connections dropped
from from ~5000 with 0.4.1.6-1 to 9 or less with 0.4.2.5-1.

In addition, my relay does not appear anymore on
https://metrics.torproject.org

The fingerprint is 33D88F331408141F2A2CC563239E54E48F7A211B

IPs are 151.127.52.79 and 2001:41d0:fecf:8900:216:3eff:fe8a:e4a6

Regards,
Clément



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