On Thu, Mar 13, 2014 at 10:21:38PM +0000, George Kadianakis wrote:
From {2}, we see that the Tor network has 6000MiB/s advertised guard bandwidth (orange line), but supposedly is only using the 3500MiB/s (yellow line). This means, that supposedly we are only using 3/5ths of our guard capacity: we have 2500MiB/s spare.
Looking back at {1}, we see that if we increase the guard bandwidth threshold to 2MB/s we will discard 1/10th of our total guard bandwidth. This is not a terrible problem if we have 2/5ths of spare guard capacity...
.oO(this sounds too good to be true, doesn't it?)
[snip]
So for example, we see that those 1000 nodes that we discarded in the 2MB/s case, only had 0.07 probability of being selected.
There's an interesting interaction here, where by being more selective about what counts as a guard, we push more relays into only being suitable for the middle hop of the circuit.
While we always talk about how the Tor network is a clique, in approximation it's really three layers:
{ fast non-exits } -------- { slow non-exits} -------- { exits}
And very broadly speaking, our proposal here pushes half of the relays from the first set into the second set.
I wonder what other effects this change has, e.g. on the expected number of file descriptors that relays of each category will use.
It would be interesting to learn, from your 6000MiB/s and 3500MiB/s numbers above, how much of that bandwidth was from what position in the circuit. For example, a pretty big fraction (by bandwidth) of the fast guards are also fast exits, so by making guard choice more selective, we're moving those relays *out* of other positions in the circuit, with implications that I don't fully understand. I don't think there's an easy way to learn this breakdown though.
Looking at it this way also makes me wonder about using Conflux to glue together two relays from the middle category, since the middle category is where the small relays go.
Or looking at it from the other direction, if we raise the threshold for being a guard to 2MB/s, and we get a bunch of volunteer non-exit relays on fast cablemodems (1MB/s), the only position we can use those smaller non-exit relays is in the middle hop. So we could imagine a world where we have a glut of extra capacity in the middle hop, since you can't exit from it and it's not concentrated enough to use any of the relays as guards.
Might we end up with oscillations, where the non-exit non-guards receive inflated consensus weights because they're underused, pushing them over the edge to get the Guard flag, under they accumulate some users and don't look so hot anymore, in which case they lose the Guard flag?
I don't think any of these issues is enough to slow us down on the general direction. But they illustrate that there's a lot more complexity underneath.
--Roger