[tor-relays] How to Limit Bridge Traffic

[entensaison at use.startmail.com]

Hi,
 
On Thursday, March 5, 2020 at 8:24 PM, Imre Jonk <imre at imrejonk.nl> 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20200306/9fc9970e/attachment.html>