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

[Tim]

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/c96d57d3/attachment.html>