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

[David Fifield]

I'm looking at the graphs for the Snowflake bridge,
https://metrics.torproject.org/rs.html#details/5481936581E23D2D178105D44DB6915AB06BFB7F

For the past year and more, the "written bytes" and "read bytes" have
matched almost identically. On 2020-02-19, they start to diverge. That
date coincides with the limited release of a version of Snowflake that
is able to run for a longer time, and a rebuild and restart of the
bridge (https://bugs.torproject.org/33336#comment:8). In the past few
days, the "read bytes" has grown to be about 10 times the "written
bytes". I'm trying to interpret this information.

1. Where does the data in the graph come from? I didn't find it covered
   at https://metrics.torproject.org/reproducible-metrics.html. I looked
   at the most recent bridge-extra-info descriptor:
	write-history 2020-03-24 14:50:48 (86400 s) 2308002816,3215030272,2062971904,3323116544,4469634048
	read-history 2020-03-24 14:50:48 (86400 s) 5265647616,8424690688,5873989632,38813471744,7116800000
	dirreq-write-history 2020-03-24 14:50:48 (86400 s) 95039488,88645632,70933504,96854016,57280512
	dirreq-read-history 2020-03-24 14:50:48 (86400 s) 2764800,1468416,1036288,2764800,2027520
   However if I just divide the write-history and read-history numbers
   by 86400, the numbers I get don't match the graph.
   			write		read
   	2020-03-20	26.7 kB/s	 60.9 kB/s
   	2020-03-21	37.2 kB/s	 97.5 kB/s
   	2020-03-22	23.9 kB/s	 68.0 kB/s
   	2020-03-23	38.5 kB/s	449.2 kB/s
   	2020-03-24	51.7 kB/s	 82.4 kB/s

2. When I look at the graphs of some default bridges, I see the written
   and read number being almost equal always.
   https://metrics.torproject.org/rs.html#details/5F161D2E5713C93F16FEEDD63178E37208AA78DF
   https://metrics.torproject.org/rs.html#details/8F4541EEE3F2306B7B9FEF1795EC302F6B84DAE8
   When I look at moria1, a directory authority, I see written being
   much greater than read.
   https://metrics.torproject.org/rs.html#details/9695DFC35FFEB861329B9F1AB04C46397020CE31
   What accounts for the equality in some cases and the inequality in
   others? What could explain the divergence in the case of the
   Snowflake bridge?

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20200324-flakey-bwhist-6m.svg.gz
Type: application/gzip
Size: 7640 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20200324/521e4398/attachment.gz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20200324-flakey-bwhist-1m.svg.gz
Type: application/gzip
Size: 1772 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/metrics-team/attachments/20200324/521e4398/attachment-0001.gz>