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

2020-01-09 Thread Felix

Hi Matt

Am 2020-01-09 um 6:58 AM schrieb Matt Corallo:

I’m sure this exists somewhere so this is more of a request-for-links, but 
what’s the current thinking on TCP CCA selection for Tor relays? While it has 
fairness issues (and reported long-tail issues for higher-latency links, though 
I can’t find good in-practice analysis of this), BBA should handle random 
packet loss much better than, eg, Cubic. This is likely less of an issue for 
western users, but many other parts of the world (especially China) see much 
higher packet loss due to regularly-overloaded links. I presume it is not good 
practice to change the default CCA for relays/bridges, but it seems BBA/BBAv2 
would be a worthwhile experiment to see if it improves the browsing experience 
for non-western tor users.

Matt


You can find a nice compare between loss less and loss based congestion
here [1].

It's difficult to say if one or the other are better in the use with
Tor. A single TCP connection between two Tor relays bundles multiple
circuits (data flows) which can result in very different needs for
congestion to connect end points.


[1] https://
heim.ifi.uio.no/davihay/hayes10__google_delay_based_tcp_conges_contr.pdf
--
Cheers, Felix
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


Re: [tor-relays] Advices about Tor Network in general...

2020-01-09 Thread yl
Hello Hugo

Am 07.01.20 um 23:08 schrieb Hugo Claude:
> 1. Is it possible to choose my relay as my guard relay while i'm using Tor 
> Network ?

I never tried this, but have a look at "EntryNodes node,node,…" here:
https://2019.www.torproject.org/docs/tor-manual.html.en

Or look at "UseBridges 0|1" and "Bridge [transport] IP:ORPort
[fingerprint]".

Make sure to test it before you rely on the intended function and the
privacy.

> 
> 2. Why my relay is running on 4.1.5 while some are 4.2.5 ect... ?

Maybe your OS is only shipping that version?

There is a release trac here:
https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTorReleases

Did you check how to add the official sources for Debian based/like
systems, there is some info here:
https://2019.www.torproject.org/docs/debian.html.en


> 
> 3. How can i make a kind of proxy to make my entire traffic passing through 
> Tor (like Orbot on mobile phone).

There is some descriptions like that in the Internet, but I'd advice
against this, you see a lot of captures when only using Tor. But there
is some guides to setup a Raspberry to act as a Tor router that does not
allow traffic to take any other route.

> 
> 4. What kind of low-budget servers (-100€), i can buy for running ≈12MB/s 
> Relays ?

From what I heard lately a Raspberry Pi 3B won't work, it will not have
sufficient CPU power, also a Pi4 seems to be a bit short in CPU power,
but I'd say something with a bit more power should be able to take
12MByte/s.

Regards
yl
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays


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

2020-01-09 Thread Matt Corallo
I’m sure this exists somewhere so this is more of a request-for-links, but 
what’s the current thinking on TCP CCA selection for Tor relays? While it has 
fairness issues (and reported long-tail issues for higher-latency links, though 
I can’t find good in-practice analysis of this), BBA should handle random 
packet loss much better than, eg, Cubic. This is likely less of an issue for 
western users, but many other parts of the world (especially China) see much 
higher packet loss due to regularly-overloaded links. I presume it is not good 
practice to change the default CCA for relays/bridges, but it seems BBA/BBAv2 
would be a worthwhile experiment to see if it improves the browsing experience 
for non-western tor users.

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


Re: [tor-relays] %include in torrc

2020-01-09 Thread ylms
Thanks for correcting my false assumption, I assumed the application is
just still called arm, but now I see the application is really outdated.
I wonder why it is not maintained in the Debian sources. But well, the
packages are sometime outdated.

Thanks for now.

yl


On 1/8/20 12:42 AM, Damian Johnson wrote:
> Hi yl, arm and nyx's author here. "Arm" is the name of the old 1.x
> codebase which was last developed in 2012...
> 
> https://nyx.torproject.org/changelog/index.html#version_1.x
> 
> If the application says 'arm' then please upgrade. :)
> 
> On Tue, Jan 7, 2020 at 3:31 PM yl  wrote:
>>
>> Hello Toralf
>>
>> Depending on the OS it is called arm or nyx.
>> I can check the log output of tor itself, I think that is the source of the 
>> nyx messages in the initial screen.
>>
>> Regards
>> yl
>>
>>
>> Am 7. Januar 2020 19:12:46 MEZ schrieb "Toralf Förster" 
>> :
>>>
>>> On 1/7/20 6:36 PM, ylms wrote:

 Is arm supposed to complain about the line with the %include as "The
>>>
>>>
>>> IMO "arm" is deprecated in favour of "Nyx".
>>>
>> ___
>> 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 mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays