On Thursday, March 5, 2020 at 8:24 PM, Imre Jonk <imre@xxxxxxxxxxx> wrote:
Hi Eddie,
On Wed, 2020-03-04 at 12:34 -0800, Eddie wrote:
Does BandwidthRate apply to bridges. I can (hopefully) guess that
RelayBandwidth doesn't.
Does the AccountingMax apply.
I am almost certain that all three options apply to bridges as well.
Note that BandwidthRate applies to all TCP data (not the TCP headers or
DNS traffic), while RelayBandwidth* applies to the _relayed traffic_
only.
I noticed the following in the manual:
If you have bandwidth cost issues, enabling hibernation is preferable
to setting a low bandwidth, since it provides users with a collection
of fast servers that are up some of the time, which is more useful
than a set of slow servers that are always "available".
Does that advice apply equally to bridges, assuming that the
Accounting options do apply. Or would it more advantageous for a
bridge to be constantly available, as switching bridges isn't as
seamless as switching relays.
That's an interesting question. Bridges are required to provide at
least 1 Mbit/s bandwidth, but I can't find anything related to uptime
requirements (except for the two hours a day minimum). I'd say that the
advice therefore also applies to bridges. The Tor client software can
be configured to use multiple bridges.
I would say the recommendation to use AccountingMax does
not apply for bridges.
It's just a subjective impression but there are often people
complaining that most bridges they get handed out don't
work or stop working after a short time.
Some of these people end up believing that they are unable to
use Tor at all from their location, because their adversary
successfully detected the bridge.
(Which might be true in some cases.)
In order to avoid confusion for people who depend on using bridges
it seems to make more sense to limit the bandwith instead.