[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #1854 [Tor Relay]: Project: Raise the minimum bandwidth for being a relay?
#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: | Points:
Parent: |
-------------------------+--------------------------------------------------
Description changed by arma:
Old description:
> 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.
New description:
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#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs