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

[Dhalgren Tor]

On Thu, Oct 1, 2015 at 11:41 PM, Tim Wilson-Brown - teor
<teor2345 at gmail.com> wrote:
>
> We could modify the *Bandwidth* options to take TCP overhead into account.

Not practical.  TCP/IP overhead varies greatly.  I have a guard that
averages 5% while the exit does 10% when saturated and more
when running in good balance.  Depends on the TCP packet
payload sizes and header options, which can  differ from
connection to connection.

> Alternately, we could modify the documentation to explicitly state that TCP
> overhead and name resolution on exits (and perhaps other overheads?) *isn’t*
> taken into account by those options. This would inform relay operators to
> take the TCP and DNS overheads for their particular setup into account when
> configuring the *Bandwidth* options, if the overhead is significant for
> them.

A good idea.  Easy to overlook even for the experienced
and a simple reminder goes a long way.

> You suggested TCP overhead was 5%-13%, I can include that in the manual.
> Do we know what fraction of exit traffic is DNS requests?

Seems relatively miniscule though I haven't dug into it.
Some resolver queries go over TCP while most are UDP.
'unbound' works so well I haven't spent much time with
it.  Have 'unbound' writing statistics to syslogd and
if I see anything useful will append it to this thread.
Some relay operators configure ISP DNS where
the cache resides on another machine.

> Are there any other overheads/additional traffic we should
> note while updating the manual?

Think that covers it.  Operator 'ssh' is nothing, relay traffic
the 1000 lb Gorilla.

> (Or would would you suggest that we update the code? I’m not sure how much
> this actually helps, as, once deployed to all relays, the consensus weights
> for all relays that set a *Bandwidth* options would come out slightly lower,
> and other relays without *Bandwidth* options set would take up the load.)

Per above, impossible to figure.  Better to remind
folks when they refer to the documentation.

What I do is have a script that writes 'ifconfig ethX' to a file
once a day, in sync with the service-provider accounting time-
zone.  Have an 'awk' script that calculates bytes for each day
--is very precise including all traffic and overheads.
The script subtracts-out MAC headers (using packet counts)
since the 14 bytes does not hit the WAN and is not billable.

Perhaps passing mention of 'ifconfig' statistics in the
manual is worthwhile.  'ip -s link show eth0X' truncates
byte counters (on some distros anyway) and is useless.