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

Tim t_ebay at icloud.com
Fri Sep 19 23:10:19 UTC 2014


[Edit: Convert to end-posting & fix quote levels]

On 18 Sep 2014, at 10:40 , Paritesh Boyeyoko <parity.boy at gmail.com> wrote:

> 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
> 
> 
> 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20140920/a451b577/attachment-0001.html>


More information about the tor-relays mailing list