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