[tor-bugs] #1854 [Tor Relay]: Project: Raise the minimum bandwidth for being a relay?

[Tor Bug Tracker & Wiki]

#1854: Project: Raise the minimum bandwidth for being a relay?
-------------------------+--------------------------------------------------
 Reporter:  arma         |       Owner:                     
     Type:  enhancement  |      Status:  new                
 Priority:  normal       |   Milestone:  Deliverable-Mar2011
Component:  Tor Relay    |     Version:                     
 Keywords:               |      Parent:                     
-------------------------+--------------------------------------------------
 Mike's performance work has shown that the smaller relays -- for example,
 the ones that set bandwidthrate and bandwidthburst to 20k -- are never
 good news to have in your circuit.

 Damon McCoy's hotpets 2010 paper showed more details of how you could
 improve performance by dumping the bottom X% of the relays.

 Of course, there's a network effect issue here: clearly you get better
 performance if you're the only one ignoring the slower relays.

 But I think there's something to this even when everybody is doing it. Our
 load balancing makes a 500KB relay 10x more likely to be used than a 50KB
 relay, but given a whole lot of users building paths, the 50KB relay will
 get overloaded more often and show worse characteristics when overloaded
 than the 500KB relay -- in large part because we're load balancing by
 circuit rather than by byte.

 So I'd like to do a series of performance experiments where the directory
 authorities take away the Running flag from everybody whose consensus
 bandwidth is under X.

 Ideally we'd do it while the network is under a variety of load conditions
 (removing capacity from the network when there's a lot of load seems like
 it would hurt us more, but then, using overloaded relays when there's a
 lot of load could hurt us a lot too).

 This could even be a research task that we try to give to a research group
 that wants to work on simulated Tor network performance. But I think
 that's a separate project.

 Along with the performance simulations we need to consider the anonymity
 implications of reducing the diversity of relays. How much anonymity do we
 lose if we treat anonymity as entropy? How much do we lose if we consider
 the location-based anonymity metrics of Feamster or Edman? Ideally we'd
 figure out some way to compare performance and anonymity so we can decide
 if we like various points in the tradeoff space. Really, we should be
 working on this piece already to analyze whether Mike's bwauth algorithm
 is worth it.

 Finally, should we consider keeping them in the network if they have nice
 exit policies?

 Relays that are too slow should be encouraged to become bridges. Even
 better, we should help people recognize when they ought to start out as a
 bridge rather than trying to be a relay.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/1854>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online