Exit Balancing Patch

[Mike Perry]

Thus spake Roger Dingledine (arma at mit.edu):

> On Wed, Jul 18, 2007 at 01:36:02AM -0700, Mike Perry wrote:
> > 1. Expand MAX_BELIEVABLE_BANDWIDTH from 1.5MBytes/sec to 10Mbytes/sec. 
> >    We already have several Tor nodes with near 5Mbytes/sec. Capping them 
> >    at 1.5MBytes/sec artifically dumps load on slower nodes.
> 
> Hi Mike,
> 
> On the theory that if I plan to answer everything I'll answer nothing,
> here is a first response to this little piece.

I like this idea. Though beware, it can lead you down the dark and
lonely road of replying to yourself 3 times on a mailinglist while
there are otherwise nothing but crickets ;)
 
> It's true that this doesn't distribute load ideally, but putting the
> cap lower than some of the running routers can prevent an attacker from
> publishing a majority of absurdly fast routers and pushing every guard
> guard out of having guard status -- similar to the attack described
> in
> https://tor.eff.org/svn/trunk/doc/spec/proposals/107-uptime-sanity-checking.txt
> 
> Actually, I just checked the code, and that attack works right now. :(

Yeah, I see no reason why this attack can't work just by picking a
bunch of routers at whatever bandwidth limit is chosen. It seems
orthogonal to this patch.

> We should consider modifying router_get_advertised_bandwidth() to cap
> its answer at MAX_BELIEVABLE_BANDWIDTH, so the smartlist we build in
> dirserv_compute_performance_thresholds() won't list the higher bandwidths.
>
> One solution would be to have a bandwidth level above which you're
> *always* guard-worthy, and a separate value for the rate-limiting stuff.

Yeah. Both values should have nothing to do with this clipping
nonsense though. It is possible to detect bandwidth liars/overloaded
nodes via other means (scanning, peer-monitoring).

> The reason this number is particularly low still is because back when
> I picked it, we had problems where Tor servers on fast pipes couldn't
> handle the throughput Tor was sending towards them (due to cpu limits,
> etc), so I needed to decrease the attention they were getting. I no
> longer have a good handle on the fast Tor servers out there right now,
> so I have no idea if this is still smart or no longer smart. We do still
> hear on or-talk from people running fast Tor servers on slow CPUs that
> are bottlenecked by AES, though. Hm.

Why does it matter if routers are CPU or network bound? From the Tor
network routing point of view, it shouldn't matter, capacity is
capacity. If it is a problem for node operators, they limit their
bandwidth in the config, problem solved. If they don't, then they just
run at 100% CPU, and Tor should still properly report their observed
bandwidth rate (unless they lie, but again, that is a another,
orthogonal matter).

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20070718/d9726a70/attachment.pgp>