[tor-dev] Implications of switching to a single guard node: some conclusions

[Roger Dingledine]

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