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

Re: Tor client performance (was Re: URGENT: patch needed ASAP for authority bug)



Thus spake Roger Dingledine (arma@xxxxxxx):

> That said, we could imagine some solutions. One solution is that your
> Tor relay can put an extra line in its descriptor specifying a maximum
> weighting it wants for itself in the consensus. Then the directory
> authorities take that into account in their bandwidth votes. This approach
> has the downside that you are limiting an artificial unitless number, so
> you may have to keep adjusting your number as the network changes around
> you. But let's take a step back -- you *already* were in that position
> before, when the unitless number was slightly more like bandwidth. By
> setting maxadvertisedbandwidth, you were reducing the proportion of
> network weightings that clients would use when allocating their traffic,
> and hoping that would somehow regulate your memory and socket load. The
> fraction of the clients you attracted was based on how many other relays
> there were and what weights they published, not (just) on the values you
> chose for bandwidthrate or maxadvertisedbandwidth.
> 
> (The reason we can't just let people choose an upper bound on sockets is
> because of the unclear anonymity implications of a non-clique topology,
> and the difficulty of telling every client what links work and what
> links don't. See e.g. http://freehaven.net/anonbib/#danezis-pet2008
> for details.)
> 
> Is my "putting an extra line in the descriptor" solution good enough? It's
> certainly a start. I'd love to hear a better idea though -- especially
> if it's either as easy to implement, or if not, comes with design and
> implementation help. :)

I think this is a bad idea, mostly for the reasons you specify above.
I feel like capping this advertised value is giving relay operators
access to a control they understand even less now than we assumed
they might before. It's at best tangentially related to load, and
it is just asking for trouble, irregular results, and more confusion.

If I want to build "Mike and Moxie's Extra-Super-Fast-Tor", for
example, I look around for all the relays that have set this value,
and blast the hell out of them because no one else is using them.
Suddenly they all complain about their resources being exhausted even
though they are supposed to be "limited."

So my question is: Why isn't bandwidthrate sufficient for these
relays? It more directly throttles the load, AND the bandwidth
authorities will actually measure you as having a lower capacity if
you set this value lower than your connection capacity.

Additionally, my experiments last year did show that relays that set a
bandwidthrate were considerably more reliable than those that did not.
This seems to be the way to go. In fact, the difference in circuit
failure rate (Figure 7) of my HotPETS paper was so marked, I had
planned on writing a script to email the contact info address of every
relay that *DIDN'T* set a bandwidth rate.

> For example, it's possible we should flatten the high end of relays as
> ordered by bandwidth. Right now the bwauthorities never vote a single
> relay's weight in the consensus to be more than 5% of the network. We
> could lower that to 3% or something. It would slow down the network as a
> whole, but it would provide more breathing room to the really fast relays.

This is also the wrong way to go. It's not just the fast relays that
are overloaded and choking on various resource constraints. Again, see
figures 7 and 8 of my HotPETS paper. Even (or perhaps for some reason,
*especially*) the slower relays are unreliable. Or at least they were
last year.
 
> Well, the problem central to this thread is "Lately, certain relays are
> receiving way more *connections* than they can handle, and it's not
> only the relays at the very top of the bandwidth charts." So I think
> it's very relevant.

Yep. See figure 8 of my HotPETs paper :)

-- 
Mike Perry
Mad Computer Scientist
fscked.org evil labs

Attachment: pgpVG7r0J4RQ2.pgp
Description: PGP signature