Send tor-relays mailing list submissions to
tor-relays@xxxxxxxxxxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
or, via email, send a message with subject or body 'help' to
tor-relays-request@xxxxxxxxxxxxxxxxxxxx
You can reach the person managing the list at
tor-relays-owner@xxxxxxxxxxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of tor-relays digest..."
Today's Topics:
1. write-history for exit relays only? (Philipp Winter)
2. Re: write-history for exit relays only? (Aaron Johnson)
3. Re: Tor and Diplomatic Immunity (Green Dream)
4. Re: Tor and Diplomatic Immunity (ITechGeek)
5. Which OS gives usually the best performance for a relay?
(Farid Joubbi)
6. Re: write-history for exit relays only? (Philipp Winter)
7. Re: write-history for exit relays only? (teor)
----------------------------------------------------------------------
Message: 1
Date: Tue, 6 Sep 2016 11:06:57 -0400
From: Philipp Winter <phw@xxxxxxxxx>
To: tor-relays@xxxxxxxxxxxxxxxxxxxx
Subject: [tor-relays] write-history for exit relays only?
Message-ID: <20160906150657.GA2619@xxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii
I want to learn how many bytes exit relays forwarded. I assume that the
write-history that is published in a relay's extra-info document
includes bytes that were relayed as part of the exit's guard and middle
role? If so, is there a way to learn how many bytes were written by the
relay in its exit role only?
I suspect that one could approximate this number by accounting for the
probability of all exits being selected as guard, middle, and exit, but
I would prefer a simpler and more reliable approach.
------------------------------
Message: 2
Date: Tue, 6 Sep 2016 12:10:06 -0400
From: Aaron Johnson <aaron.m.johnson@xxxxxxxxxxxx>
To: tor-relays@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-relays] write-history for exit relays only?
Message-ID: <6FEEF628-5016-4F5A-B0DC-087053CBD1C7@xxxxxxxxxxxx>
Content-Type: text/plain; charset=utf-8
> I suspect that one could approximate this number by accounting for the
> probability of all exits being selected as guard, middle, and exit, but
> I would prefer a simpler and more reliable approach.
This doesn’t seem like a bad approximation to me, given that for as long as I have been aware, exits have had zero probability of being chosen in any position other than the exit position.
Aaron
------------------------------
Message: 3
Date: Tue, 6 Sep 2016 11:29:27 -0700
From: Green Dream <greendream848@xxxxxxxxx>
To: tor-relays@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-relays] Tor and Diplomatic Immunity
Message-ID:
<CAAd2PD+755jb-hU++H8BTuWDkkNMKbDy2LFmaZLXontT5DgpOw@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=UTF-8
The whole idea doesn't sit right with me.
For one, I'm not sure I'd want any more Five Eyes entities running
Exit nodes. Most embassies are already a haven for espionage activity.
You'd pretty much have to assume they'd be sniffing the exit traffic.
Also, with all the other priorities, I kinda doubt most embassies have
any interest in the general work involved, not to mention the
liability, of running an Exit.
------------------------------
Message: 4
Date: Tue, 6 Sep 2016 14:49:56 -0400
From: ITechGeek <ITG@xxxxxxxxxxxxx>
To: tor-relays@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-relays] Tor and Diplomatic Immunity
Message-ID:
<CAN2EnhD7E=DYynJDGr+Pu-Vx7wMQGN6FV5KdgksGT8VK42HOxA@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
On Tue, Sep 6, 2016 at 2:29 PM, Green Dream <greendream848@xxxxxxxxx> wrote:
> For one, I'm not sure I'd want any more Five Eyes entities running
> Exit nodes. Most embassies are already a haven for espionage activity.
> You'd pretty much have to assume they'd be sniffing the exit traffic.
>
I doubt Five Eyes countries embassies would bother running tor since they
have budgets to easily encrypt and funnel all their traffic back to their
home countries.
If anyone would be running tor nodes, I would imagine it would be countries
w/ smaller budgets who would be looking for more cost effective ways to
make their traffic hard to sniff.
-----------------------------------------------------------------------------------------------
-ITG (ITechGeek) | ITG@xxxxxxxxxxxxx <
https://itg.nu/>
https://keybase.io/itechgeek |
https://itg.nu/
Google Voice: +1-703-493-0128 / Twitter: ITechGeek / Facebook:
http://fb.me/Jbwa.Net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.torproject.org/pipermail/tor-relays/attachments/20160906/9c226ed9/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 6 Sep 2016 20:14:38 +0000
From: Farid Joubbi <joubbi@xxxxxx>
To: "tor-relays@xxxxxxxxxxxxxxxxxxxx"
<tor-relays@xxxxxxxxxxxxxxxxxxxx>
Subject: [tor-relays] Which OS gives usually the best performance for
a relay?
Message-ID: <1473192878111.13336@xxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
Hello,
I am thinking of setting up a new relay.
I know that the hardware in the server is going to be the bottleneck, not my Internet connection.
I have a problem deciding on which OS to use for the relay.
A few years ago when I had a similar relay going, I had it running on OpenBSD first.
Then I changed the OS to FreeBSD and the performance got about 20% better.
I have no idea if this would be the case today too.
So I think that maybe it's either FreeBSD or Debian that would be "best", but I have nothing concrete to base that decision on unless I try them both.
I am going to use a Via C7 board in this specific case. So I suspect that it's the maturity of the VIA drivers in the OS that is going to make the difference. Still I would like to know how to think in similar situations in the future even for other hardware.
Has anyone any concrete experience of the tor relay speeds on different operating systems?
I don't want to start a flame war of religious beliefs, but I suspect that OSes differ in how optimized they are for different tasks.
Thankful for any constructive input on this.
Regards,
Farid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
http://lists.torproject.org/pipermail/tor-relays/attachments/20160906/311d8e64/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 6 Sep 2016 16:36:23 -0400
From: Philipp Winter <phw@xxxxxxxxx>
To: tor-relays@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-relays] write-history for exit relays only?
Message-ID: <20160906203623.GB2619@xxxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
On Tue, Sep 06, 2016 at 12:10:06PM -0400, Aaron Johnson wrote:
> > I suspect that one could approximate this number by accounting for the
> > probability of all exits being selected as guard, middle, and exit, but
> > I would prefer a simpler and more reliable approach.
>
> This doesn’t seem like a bad approximation to me, given that for as
> long as I have been aware, exits have had zero probability of being
> chosen in any position other than the exit position.
Thanks, Aaron. You are right. Section 3.8.3 in dir-spec has the answer:
<
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2611>
I just proved this to myself with the small attached Python script.
Currently, exit bandwidth is the network's scarce resource, which is not
surprising since running an exit is riskier than running a guard or a
middle. Since exits are scarce, the bandwidth weights in case 3,
subcase A are currently in place:
<
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2726>
In that case, the specification hard-codes the probability of an exit
taking on a non-exit role (Wgd, Wmd, and Wme) to 0.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bandwidth-weights.py
Type: text/x-python
Size: 1318 bytes
Desc: not available
URL: <
http://lists.torproject.org/pipermail/tor-relays/attachments/20160906/cf321b8e/attachment-0001.py>
------------------------------
Message: 7
Date: Wed, 7 Sep 2016 08:39:24 +1000
From: teor <teor2345@xxxxxxxxx>
To: tor-relays@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-relays] write-history for exit relays only?
Message-ID: <A6898E13-C01F-441A-B392-2912376AB7D4@xxxxxxxxx>
Content-Type: text/plain; charset="utf-8"
> On 7 Sep 2016, at 06:36, Philipp Winter <phw@xxxxxxxxx> wrote:
>
> On Tue, Sep 06, 2016 at 12:10:06PM -0400, Aaron Johnson wrote:
>>> I suspect that one could approximate this number by accounting for the
>>> probability of all exits being selected as guard, middle, and exit, but
>>> I would prefer a simpler and more reliable approach.
>>
>> This doesn’t seem like a bad approximation to me, given that for as
>> long as I have been aware, exits have had zero probability of being
>> chosen in any position other than the exit position.
>
> Thanks, Aaron. You are right. Section 3.8.3 in dir-spec has the answer:
> <
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2611>
>
> I just proved this to myself with the small attached Python script.
> Currently, exit bandwidth is the network's scarce resource, which is not
> surprising since running an exit is riskier than running a guard or a
> middle. Since exits are scarce, the bandwidth weights in case 3,
> subcase A are currently in place:
> <
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n2726>
>
> In that case, the specification hard-codes the probability of an exit
> taking on a non-exit role (Wgd, Wmd, and Wme) to 0.
> <bandwidth-weights.py>
It's also worth noting that Exits will serve directory documents and hidden service descriptors, and act as introduction and rendezvous points, so your estimates could be a few percentage points off.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <
http://lists.torproject.org/pipermail/tor-relays/attachments/20160907/9852a20a/attachment.sig>
------------------------------
Subject: Digest Footer
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
------------------------------
End of tor-relays Digest, Vol 68, Issue 21
******************************************