[tor-dev] Scaling tor for a global population

[isis]

Griffin Boyce transcribed 2.7K bytes:
>   I'd say that the idea to 'downgrade' people into being bridges is a good
> one, if done without requiring user input.  'Everyone run a relay' might
> only be useful because so many of the people we say it to have fast
> connections.  It seems reasonable to filter out persistently low connections
> (and allow them back in if their connection speed improves).  That is not to
> say that every potential bridge should actually be accepted as a bridge.
> The 28B/s bridge is nuts - either it's on an embedded device or their torrc
> is misconfigured.

I do remember that 28 B/s bridge had an Advertised Bandwidth which was a much
higher number, but I don't recall precisely. (However, because there isn't
currently any Bandwidth Authorities for bridge relays, bridges can easily lie
about their bandwidth. Currently, we would have no way, once a slow/junk relay
is downgraded to a bridge, to check its bandwidth.)


>   What I usually recommend is to users is based on their bandwidth and how
> frequently their IP changes.  If their connection is fast and their IP never
> changes (eg, a desktop or server), then run a non-exit relay [2].  For a
> laptop that moves to-from work, then a relay or bridge.

Actually, anything with a constantly changing IP is a terrible idea for a
bridge.

Think of it this way: BridgeDB hands you a bridge line on Monday. On Tuesday,
the bridge's IP rotates to something else. Now your Tor doesn't work. Wah-wah,
sucks for you!

Or how about this one: BridgeDB hands you a bridge line on Monday. On Monday
night in whatever timezone the bridge's operator lives in, the bridge operator
carries their laptop (and, hence, the bridge) home from work. Now your Tor
doesn't work! On Tuesday morning, the bridge operation carries that laptop
back to work. All of a sudden your Tor works again! Repeat! Now you're super
confused, and you're likely to just complain that "Tor is janky/unreliable!"


> If it moves a *lot*, use Cupcake (which is a wrapper for flashproxy).

Okay, running flashproxies on things which have constantly changing IPs *is* a
good idea. But those are flashproxies, not real Tor bridges, and we should be
careful not to confound them.


> Running a relay on a raspi or a router (?!) is not a great idea -- though
> people attempt both.  If things could gracefully switch from being a relay
> to a bridge based on their speed, then that would actually make it more
> straightforward for users because they don't have to worry about whether
> they should be a bridge or relay.
> 
>   People can't really estimate their own bandwidth without something like
> NDT, but they have an idea of how fast it is. eg, this connection is 21Mb/s
> up, 6mb/s down, but that's mostly irrelevant because my perception of it is
> that it's Fast.  That perception would be the same if I were getting 2Mbp/s
> up/down.  So maybe one non-technical change we can make is to user education
> and website documentation -- run a relay if you have a Fast connection.
> 
>   Filtering people out based on advertised bandwidth is tricky - advertised
> bandwidth is only useful if it's based on reality.

Confusingly, the "Advertised Bandwidth" *is* actually reflective of reality:
the Bandwidth Authorities determine it, and then (optionally) it is capped at
whatever the relay set `MaxAdvertisedBandwidth` to in the relay's torrc.


> 250kb/s seems like a reasonable floor for both relays and bridges.  100kb/s
> is kind of the sanity check for a distributed bridge - if it's below that,
> it's not useful enough IMO.

You probably already know this, but for everyone else, see my note above about
how bridge bandwidths currently aren't measured at all.


>   The real questions for me are: how much of a gain is possible?

Mike Perry gave some pretty concrete numbers.


> and what is the right balance between number of relays and speed of those
> relays?

See my original reply to Mike's post, particularly the calculations underneath
suggestion #2 where I came up with how we'd find a sliding "sweet spot" where
the network is not degraded overall by advertising relays which are too slow
to compensate for the cost of advertising them.


>  and I suspect that until something is tried, it may just be speculation.

I respectfully disagree. I'm pretty sure I just calculated and analysed some
statistics on some pretty concrete numbers derived directly from current
network usage and relays. :)

-- 
 ♥Ⓐ isis agora lovecruft
_________________________________________________________
GPG: 4096R/A3ADB67A2CDB8B35
Current Keys: https://blog.patternsinthevoid.net/isis.txt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1154 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20140929/e5845004/attachment-0001.sig>