[Edit: Convert to end-posting & fix quote levels]
On 18 Sep 2014, at 10:40 , Paritesh Boyeyoko parity.boy@gmail.com wrote:
On Wednesday 17 Sep 2014 22:40:36 Tim wrote:
On 17 Sep 2014, at 22:00, Paritesh Boyeyoko parity.boy@gmail.com wrote:
On Tuesday 16 Sep 2014 17:36:41 Toralf F?rster wrote:
On 09/16/2014 03:35 AM, Paritesh Boyeyoko wrote:
Hello -- So, I was thinking that in the same way that Tor relays have port-based exit policies, could they not also have port-based entrance policies? I
Beside the general answer (probably "NO") - you mean something, which cannot be handled by a firewall ?
@Toralf Correct, this has nothing to do with firewalls. This is more about better utilisation of slow circuits/relays by deliberately choosing to push relatively lightweight traffic across them. IRC and XMPP do not need 10Mbit/s circuits, not even close. I'm not sure how Tor clients choose the relays they use to build a circuit, and I do realise that a) there are probably more slow relays than fast ones b) attempting to pre-build both a "fast circuit" and a "slow circuit" will reduce the number of candidates for each. I'm just looking for ways to drive more traffic across slow relays. :)
Paritesh,
I think it might help to make a distinction between latency (delay) and throughput (capacity), both of which are affected by router speed:
IRC, XMMP and SSH need low latency circuits, which are mostly correlated with high bandwidth relays.
Web Browsing (HTTP/S) and similar generally need both low-ish latency and high throughput, also correlated with high bandwidth relays.
File Downloads (HTTP/S, BitTorrent) can cope with high latency as long as the throughput is high (and the reliability is sufficient, but that's another matter).
But I can't actually see much need for high latency, low throughput relays - are there many protocols that would find that useful? (SMTP is the only one that comes to mind.)
T
Hi Tim --
Very good points, and yes most likely the mail protocols would be candidates for "slow", high latency circuits.
However, there may be another class of relays that's overlooked - many VPS providers sell VPSes with low data caps, even on fast connections (100Mbit/s). There are two ways to address this:
a) traffic accounting: the relay hibernates until the next reset b) throttling so that the data cap for the month isn't prematurely reached.
I'd imagine that most relay operators with such VPS packages will choose to throttle and keep the relay up and running continuously rather than having it hibernate (I know I've had to do this in the past). The actual connection is fast enough to not suffer real latency issues, it's just the relay doing the throttling
- do you think throttling to 0.5Mbit/s or 1Mbit/s will create issues of high latency?
I'm about to go and read the Conflux paper:
"In this paper, we present Conflux, a dynamic traffic-splitting approach that assigns traffic to an overlay path based on its measured latency. Because it enhances the load-balancing properties of the network, Conflux considerably increases performance for clients using low-bandwidth bridges."
This would obviously create better utilisation of circuits as a whole, so it may well make my idea totally redundant. :)
Cheers,
-- Paritesh Boyeyoko
Paritesh,
For fast Tor relays with low data caps, the general advice is I've heard is two-fold: * enable AccountingMax, which will hibernate the router when the bandwidth is used up, and * disable directory caching to save (upload) bandwidth (AccountingMax does this automatically when it's configured)
This means that the network has many fast routers each covering some of the day/week/month, rather than many slow routers for the entire month. (It also uses the entire bandwidth quota more efficiently - what if the calculated bandwidth limit is too low?)
Tor seems to need more fast routers to reduce latency, because there is a long tail of slower routers which can provide significant capacity when needed.
T