- tor-relays - lists.torproject.org

Questions
by francois.pasgloup＠netcmail.com 16 Oct '11

16 Oct '11

2 1

icecat
by mick 09 Oct '11

09 Oct '11

Resending because I sent from the wrong address.... Begin forwarded message: To: tor-relays(a)lists.torproject.org Subject: icecat All I have now had a total of three abuse requests from the ISP hosting one of my tor nodes from a company called icecat (rip(a)icecat.biz) On the first two occasions I pointed to the notice on my server about it being a tor node and they went away. This time they are threating to null route my server if I don't do something. So reluctantly I have added a reject of 87.255.38.35:* to my exit policy. I'd be interested to hear from any other operators who have been pestered in this way about supposed abuses of icecat. Best Mick --------------------------------------------------------------------- The text file for RFC 854 contains exactly 854 lines. Do you think there is any cosmic significance in this? Douglas E Comer - Internetworking with TCP/IP Volume 1 http://www.ietf.org/rfc/rfc854.txt ---------------------------------------------------------------------

2 1

Relay accounting calculations
by Steve Snyder 05 Oct '11

05 Oct '11

I'm not sure I understand how the relay accounting limit is calculated. The manual says that you might specify an AccountingMax limit of 1 GB, a ceiling that would be applied to each of the input and output traffic. The manual also says that it is known the output traffic can be larger than the input traffic, especially if you're running an exit node. (I imagine that the converse applies if you also have Tor clients on the same network, using the node, though the manual doesn't say so.) Given that the AccountingMax value applies to traffic in each direction, one would have to specify a rate that is half their actual limit. That is, given a 100GB limit one would specify "AccountingMax 50 GB" in the config file, causing the relay to sleep when 50GB is reached in either input or output traffic. Is the algorithm really this inflexible? If I reach 50GB on output traffic, with only 49GB of input traffic, that puts the relay into hibernation with 1GB of bandwidth left unused. That seems counter-intuitive to me. Is the manual inaccurate, or am I just missing the hidden genius of tracking input and output traffic as distinct pools? It seems more sensible to specify the full bandwidth allotment, with the relay hibernating when the sum of the input and output traffic reach that limit.

2 1

Hibernation timing & bandwidth
by Steve Snyder 05 Oct '11

05 Oct '11

I have a relay with a fixed monthly bandwidth limit, so I expect the relay to hibernate toward the end of the month. (I'm trying to spread the bandwidth out over the month, but actual relay utilization cannot be estimated accurately.) I'm wondering how to time this hibernation period. What I'd like to avoid is hibernating during a period when relay hibernation is common. If I know that most Accounting-limited relays hibernate at, say, the end of the calendar month, then I can schedule my hibernation to be at the start of the calendar month. If most hibernation is done on Saturday (day 6, the end of the week) then I can arrange to sleep on Wednesday (day 3). Is there a known trend to relay hibernation that I can schedule against? Thanks.

2 1

bad line
by cmeclax-sazri 05 Oct '11

05 Oct '11

You may have noticed a deterioration in my throughput over the past month. Yesterday I called my ISP, trying to figure out the problem, and was advised to put one computer directly on line and see what happens. I did this for an hour about 20:00 UTC, taking Tor and the mail server off line, and connecting just the laptop, on which I did pings. I saw 25% packet loss with no uploading or downloading (the laptop does have a Tor client, but I was not using it). Further testing with 2ping shows that the packets lost are incoming. Hopefully the problem will be resolved either early next week or the week after (I'll be out part of the week). cmeclax

1 1

Response back from DataCell/Iceland
by Patrick Hooker 30 Sep '11

30 Sep '11

I wrote a nice letter to DataCell about the bandwidth my Tor router was using and got a quick and good response. It also sheds some light on Datacell's(in Iceland) connectivity to the outer world. " Bandwidth in Iceland is an issue in terms of most ISP's charge by the gigabyte transferred. This is the case because most ISP's depend on Vodafone or Siminn for their backhaul and those charge by the transferred Gigabyte on the international side while they don't charge for national transfer. They do that because they pay outrageous prices on the link to central europe and probably because they want to make a lot of money too ;-). Our connectivity does not depend on them however. We managed to get a somehow acceptable price for international connectivity. Its still 5 times higher than bandwith in central europe but its at least not 50 times as high as the first offers we got. At the moment we have excess capacity. Our links are loaded like less than 1%. Once we get more customer, the link will be filled up. Our infrastructure is configured to use fair queuing. This means that every IP in our network gets a fair share of the bandwidth which is the way we operate. I don't mind having traffic on the excess bandwidth as long as all customers get their guaranteed part. If it would become an issue we would enforce it by using rate limits." So, for now anyway, there doesn't seem to be a problem with my running nearly 100GB/day through my Tor middle router. The TOS excludes the running of open mail proxies doing anything illegal (by Iceland's laws), this to be expected. I can see nothing in the TOS would directly rule out Tor, at least a non-exit router. All my contact with DataCell has been very friendly, I'd recommend them to anyone who can afford ~US$70/mo. for a virtual server. Just remember that when in Iceland, never carelessly throw stones and be polite to the littl' people. Bless Bless, Patrick

1 0

Updating arm
by Bill White 30 Sep '11

30 Sep '11

Hello all -- I'm running a brand-new relay (Diogenes) and at the same time I've discovered arm, which I find an excellent way to learn the art of running a Tor relay. I'm also a Linux beginner, so please forgive my ignorance about my question. My relay is now running arm v. 1.4.0.2, and I want to upgrade to the latest version, 1.4.4. I have downloaded and extracted the tarball (http://www.atagar.com/arm/download.php) However, running ./configure, and every combination of "how to" install/upgrade I can find, results in failure. And "sudo apt-get install tor-arm" tells me I already have the most recent version posted in the repository, which is where I obtained my original arm install. Can someone help me upgrade arm to the latest version? I'm running Ubuntu server 2.6.38-8-server x86_64 Thanks in advance, -- Bill

3 7

Introduction
by Patrick Hooker 29 Sep '11

29 Sep '11

Greetings, Thought I'd say a quick hello since I'm following the list for several days now. I'm running a non-exit relay, "Anonimulo" on a VPS account I have in Iceland. I'm not sure how long I'll be able to keep it up, I may need the bandwidth/CPU time for other activities in the future. For now I'm giving 1MB/s to Tor. I had been wondering just how to monitor my relay when I read about ARM on this list. I installed ARM, fiddled with the torrc a bit and was pleasantly surprised with ARM's display. Kudos to the developer! It appears that Anonimulo is running flat out at max bandwidth too. Yay! Patrick

4 5

Re: [tor-relays] max / burst speed
by Rick Huebner 29 Sep '11

29 Sep '11

On 9/27/2011 1:37 PM, "Steve Snyder" <swsnyder(a)snydernet.net> wrote: > Either there is simply not enough traffic to saturate all available middle nodes or Tor's node selection algorithm is, um, sub-optimal. I just started my relay a month ago, so I've done some research, and it seems to be pretty complicated. Please excuse what turned into an over-long post, but I think this is info that new relay operators don't generally know, and should. At its base, the traffic allocation scheme is elegantly simple: each client randomly selects circuit participants based on the sum of all the relays' bandwidth values from the most recent consensus (not counting complications like starting with a guard node, ending with an exit, etc.). So ideally, a relay with twice the bandwidth of another will (on average) be selected for circuits twice as often, and (again, on average) end up processing twice as much traffic. And also, if the total bandwidth demand from all clients is enough to consume, say, 60% of all Tor relays' available bandwidth, each relay will (on average) be kept operating at about 60% of capacity. But... the bandwidth figure in the consensus that clients use to select relays is not a simple figure. Apparently, it used to be based on the rates reported by each relay in their uploaded server descriptors, but people tried to game the system and fed it bogus data, so that was replaced by the authoritative servers going out and measuring the actual bandwidth of each relay by downloading a test file through it to see how fast it really went. So the values your relay uploads in the descriptor are ignored now, and your set Rate and Burst speeds aren't relevant for traffic allocation except in as much as they affect the speed that the official bandwidth scanner can download the test file through you. The only bandwidth figure that matters for driving traffic to your relay is the one reported in the consensus, which you can see at https://metrics.torproject.org/networkstatus.html, or from your own relay's DirPort at http://<relay>:<dirport>/tor/status-vote/current/consensus if you're a directory mirror. Note that these are not the values from any of the TorStatus servers, they're displaying something else entirely (and not always the same thing as each other, either). So anyway, don't expect a change in your torrc file to immediately bring you more traffic. Your relay has to get rescanned first, which probably only happens once a day. OK, fair enough. But those bandwidth numbers aren't just the simple speed which was seen when the scanner last downloaded a test file through your relay. To smooth out random speed changes as your relay is remeasured day to day, the bandwidth scanners use some kind of fairly slow exponential moving average of your download speeds. So it takes considerable time for changes in your relay's speed to slowly seep into the bandwidth number in the consensus. And for new relays, it seems that the initial value which the new measurements are slowly averaged into starts out pretty low, so that your reported bandwidth also starts out pretty low, and then gradually rises over time to somewhere around your actual Rate limit. And by slow, I mean weeks; my new relay has been running for a month, and over that time, I've seen the reported bandwidth slowly, with many fits and starts and temporary setbacks, go from about 20-30 to ~200 (about half my actual Rate limit), and it's still rising. Which kind of has the effect of putting new relays on probation, and slowly feeding them more and more traffic over time to see how they do, which is not a bad thing at all. But new relay operators are usually excited and anxious to see stuff happen, and need to be aware of this slow starting ramp up period and not get too discouraged or give up because they're not seeing much traffic at first. OK, so the bandwidth rating that matters is measured and slowly averaged... but there's yet another layer. To improve the overall performance of the Tor network, and to help clients generally create faster circuits, there's another bias factor thrown in. I don't know the details, but faster relays have their measured bandwidth figures artificially boosted to drive even more traffic through them than their high bandwidth would naturally attract, and/or slower relays have their bandwidth figures artificially lowered to drive less traffic through them (not sure which or both, but the effect is the same regardless). So if the overall client bandwidth demand is, again, 60% of the total Tor network bandwidth available, instead of each relay being at ~60% capacity, the fastest relays will be more fully utilized, and, unavoidably, that means that the slower relays will be correspondingly less utilized. This might dismay slower relay operators who feel that they're being prevented from contributing as much as they'd like, but objectively, it's generally better for a Tor client to have a 300 KB/s circuit hop than a 30 KB/s one. The faster relays are just nicer for clients to use, and it's better overall for the Tor network to make sure they get used as much as possible. And if those fast relays are getting more than their prorated "fair" share of usage based on their actual speeds, that unavoidably means that slower relays are getting less usage than their speed would normally merit. But that doesn't mean the slower relays are useless! Simply by existing, those extra relays greatly increase the difficulty of various attacks on Tor, just because they *might* have been used for any given circuit. Also, the whole guard node system for making certain nasty attacks infeasible relies on having lots of potential guard nodes to choose between, even relatively slow ones. And of course, all exit nodes are especially precious, almost regardless of speed. And finally, even if they're not used all that much while client demand on the Tor network is low to moderate, they provide an important spare reserve of bandwidth to make sure that some relay somewhere will always be ready to handle a new circuit even if the network becomes very busy and manages to max out the high speed "backbone" relays, or Tor is subjected to some kind of DOS attack. So anyway, for all the relay operators asking "why isn't my relay being used more?", there's your infodump. If it's a new relay, or you recently upgraded/raised your speed limits, keep an eye on the official bandwidth figure for your relay in the consensus, especially the nice graph displayed in the Router Detail page that you reach by clicking your router link on the https://metrics.torproject.org/networkstatus.html page. If that graph shows any upwards trend, the effects of your change are still slowly percolating into your official bandwidth figure, and more traffic will appear as it rises. If it's plateaued out, you're getting your share of the overall Tor traffic based on your relay's overall performance and the total client demand on the Tor network. For slow nodes who've limited their overall Rate to avoid hitting bandwidth caps, you might consider using AccountingMax to cap the usage to a safe level, and increase your speeds; you may find it more rewarding to relay significant traffic for 6 hours per day and then hibernate for 18 than to stay on "inactive reserve" status all the time. From the overall viewpoint of the network, is it better to have 1000 new relays at good speeds up 1/4 of the time (effectively adding 250 new fast relays), or to have them at slow speeds all of the time, not being used much? I'm not really sure, but I've noticed that the AccountingMax hibernation feature is hardly used at all from what I see on TorStatus, and I wonder why. OK, enough already, this turned out way longer than I was expecting. Hope it helps.

4 4

(no subject)
by Tim Myers 28 Sep '11

28 Sep '11

Stop Sent via BlackBerry by AT&T

3 2