[Edit: Convert to end-posting & fix quote levels] On 18 Sep 2014, at 10:40 , Paritesh Boyeyoko <[email protected]> wrote:
> On Wednesday 17 Sep 2014 22:40:36 Tim wrote: > >> On 17 Sep 2014, at 22:00, Paritesh Boyeyoko <[email protected]> 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
_______________________________________________ tor-relays mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
