[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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



On Fri, Sep 19, 2014 at 6:10 PM, Tim <t_ebay@xxxxxxxxxx> wrote:
> [Edit: Convert to end-posting & fix quote levels]
>
> On 18 Sep 2014, at 10:40 , Paritesh Boyeyoko <parity.boy@xxxxxxxxx> wrote:
>
> On Wednesday 17 Sep 2014 22:40:36 Tim wrote:
>
> On 17 Sep 2014, at 22:00, Paritesh Boyeyoko <parity.boy@xxxxxxxxx> 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
Hijack thread:
So what is the advice to get a relay used more? Currently my relay
won't even get close to the AccountingMax (4TB/mo) even though the
BandwidthRate is set high enough (3MB/s). It seems like the network
considers my AdvertisedBandwidth lower than what it should be. Or
maybe because it is just a new relay in the network and still is in
the 60day ramp-up period? The ISP advertises 40Gbit in and 125mbit
out, so it should be fast enough to reach AccountingMax every month.
Thoughts? Do I artificially increase my bandwidth rate to help the
network more or will it come into equilibrium soon and reach
AccountingMax?
-Jeremy
_______________________________________________
tor-relays mailing list
tor-relays@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays