[tor-relays] excessive bandwidth assigned bandwidth-limited exit relay

Dhalgren Tor dhalgren.tor at gmail.com
Fri Oct 2 12:17:24 UTC 2015


On 10/2/15, jensm1 <jensm1 at bbjh.de> wrote:
> You're saying that you're on a 1Gbit/s link, but you are only allowed to
> use 100Mbit/s. Is this averaged over some timescale?

More than 100MB which is 60 TB/month total for both directions.
Is 100 TB/month, a common usage tier.  Has a FUP (fair usage
policy) attached, which means that the bandwidth should be
evenly consumed over accounting interval rather than in
in bursts.

> If so, you could
> try and play around with the 'RelayBandwidthBurst' setting. Increasing
> the Burst might help reduce the queue delay when you're near saturation,
> assuming the traffic is not constant

Would make it worse, not better.  A higher burst rate will
allow the measurement to increase; the average limit
must stay the same regardless.  Best to set burst-max ==
average max.  Tor relays allow some bursting regardless
of the BandwidthRate setting anyway.

>and you're not over-saturated most of the time.

This is the problem and the assumption is not correct.
The link is saturated MOST of the time due to the
overrating.

> I don't know the measuring system, but I doubt that random packet
> dropping with iptables will have a noticeable effect on the measured
> bandwidth, as long as you don't drop enough packets to horribly degrade
> user experience.

NOT RANDOM.  iptables will drop packets above the
configured rate--exactly the same as a switch
port dropping egress packets in excess of 100 MBit,
a common lower-speed attachment type.

At present the bandwidth measurement system
assesses bandwidth-constrained links that drop
above-rate packets more correctly than unconstrained
links where the relay daemon rate-limits via
queuing and protocol flow-control.

To have the relay in question rated properly
the best idea so far is to add an iptables rate
limit to the mix.  Will test keeping the
BandwidthRate setting set slightly below the
iptables limit in case that works better than
an iptables limit alone.


More information about the tor-relays mailing list