[tor-relays] Port-Based Best-Fit Circuit Selection

[Paritesh Boyeyoko]

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.boyeyoko at gmail.com

On Wednesday 17 Sep 2014 22:40:36 Tim wrote:

On 17 Sep 2014, at 22:00, Paritesh Boyeyoko <parity.boy at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140917/98b4de1d/attachment.html>