[metrics-team] How to interpret written/read bytes per second in Relay Search?

[teor]

Hi David,

>> On 26 Mar 2020, at 05:01, David Fifield <david at bamsoftware.com> wrote:
> On Wed, Mar 25, 2020 at 09:42:48AM +0100, Karsten Loesing wrote:
>> 
>>> 3. Roger found a case where traffic tagged with a 0.0.0.0/8 address was
>>>   being ignored by some part of tor's internal bandwidth accounting
>>>   (https://bugs.torproject.org/33693). Until recently, the Snowflake
>>>   bridge had a bug where, for certain clients, it reported a client
>>>   address of 0.0.0.0 to the tor bridge's ExtORPort (https://bugs.torproject.org/33157).
>>>   The bug is only partially fixed--we now report no address at all for
>>>   the affected clients. The fix was not deployed until 2020-02-22, so
>>>   it doesn't explain the divergence of read/written on its own. Do you
>>>   know offhand whether an apparent client address of 0.0.0.0, or no
>>>   address at all, would cause problems with measuring usage?
>> 
>> I'm afraid I don't know. I wonder if teor knows more about this, as he
>> spent some time on bandwidth statistics for IPv6 traffic statistics
>> recently.
> 
> Doing a quick test just now, in the absence of an Extended OR Port
> USERADDR command, the tor bridge will default to the remote IP address
> of the socket, which is 127.0.0.1:XXXX because it's coming from the
> pluggable transport server on the same host. As far as I can tell,
> 127.0.0.1 is ignored for bandwidth accounting just as 0.0.0.0 is.
> 
> Obviously the correct solution in this case is to fix #33157 and have
> the Snowflake proxies report the correct client IP address in 100% of
> cases. But it makes me think that it would be nice to have a token or
> designated address that means, I don't know what the client IP address
> is, but please count its bytes anyway. In meek we can rely on the CDN
> setting an X-Forwarded-For header, and in Snowflake we have the proxy
> attempt to extract the remote IP address of the peer-to-peer connection
> and attach it to the WebSocket request as a URL parameter. But I'm
> thinking about a DNS-based transport and there's no way to cause a
> recursive DNS resolver to forward the client's IP address to the
> authoritative resolver. (There is RFC 7871, but some DNS servers do not
> support it by design, and it's only a prefix anyway.) It would be nice
> to have clients counted even if they cannot be geolocated.

I looked at this code in tor a few weeks ago, as part of the relay
IPv6 statistics work.

Internal addresses aren't counted for statistics (or accounting).

It wasn't very well documented, so I improved the comments:
https://github.com/torproject/tor/commit/98899f20ad22e97c03235cfe13ff1fe416a15509#diff-13f67a11cfe3a7a0ff3aa39f2b87a2dc

Here's the list of Tor's current internal addresses:
https://github.com/torproject/tor/blob/686494f0f71b9235399b8241aba3e0c2fcb03ea1/src/lib/net/address.c#L241

As a workaround, you can set:
CountPrivateBandwidth 1
in the bridge torrc.

If you wanted a token, you could draw it from a documentation address
block:
https://tools.ietf.org/html/rfc5737#section-3

These addresses shouldn't appear on local networks or the internet.
(But tor doesn't ignore them yet, because it doesn't have any concept
of "unacceptable for use anywhere".)

But let's check with a Nick and others before we do that. Otherwise,
you might find those addresses get ignored in future.

T

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20200327/5c11f66a/attachment.html>