Hello --
First of all, let me apologise if this has been covered before on this list.
A couple years ago I took more than a passing interest in Tor and decided to run a non-exit relay on a VPS, which lasted until an upstream provider complained. I've recently set up another one, and while it settles into the network, it got me thinking about utilization. Much has been made of the fact that Tor is circuit-based rather than packet-based, and also of the fact that faster relays attract more traffic.
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? In other words, cause deliberate selection of a "slow" path based on the protocol intended to be used. So for example, HTTP would favour faster circuits, while the likes of email (POP, IMAP, SMTP), XMPP and IRC would favour slower circuits (being mostly text-based).
Perhaps the entrance policies could be maintained on-network (perhaps with "authority servers", with clients downloading the policies when they start up, rather than having them hard coded or configured client-side?
Just some ideas. :)
Best,
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. :)
Best,
tor-relays@lists.torproject.org