Re: [tor-dev] Progress on hidserv-stats Metrics integration, request for code review

[Karsten Loesing <karsten@xxxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/03/15 17:08, A. Johnson wrote:
>> Looking forward, hidden-service statistics are now available on
>> Metrics:
>> 
>> https://metrics.torproject.org/hidserv-data.html
> 
> Looks great!
> 
>> - Total hidden-service traffic in Mbit/s (per day, using
>> weighted interquartile mean, like lower graph on page 1 of the
>> PDF)
>> 
>> - Unique .onion addresses (per day, using weighted interquartile 
>> mean, like upper graph on page 1 of the PDF)
> 
> These seem like a good idea.

Great!  I started with the second graph, because it seems least disputed:

https://metrics.torproject.org/hidserv-dir-onions-seen.html

>> - Fraction of relays reporting hidden-service statistics
>> (containing both dir-onions-seen and rend-relayed-cells, like
>> page 3 of the PDF)
> 
> This is probably less interesting to most people, but it is
> important to people serious about understanding the meaning of the
> data. So I could take this or leave it.

Agreed.  I'll leave this graph out for the moment.

>> Note that I left out "fraction of traffic", because we can't
>> guarantee that our many assumptions we made for the blog post
>> will hold in the future.  Happy to be convinced otherwise.
> 
> The calculation of client traffic fraction assumed that most
> traffic from exit relays was in fact exit traffic. The validity of
> that assumption may indeed change in the future, depending
> especially on how the consensus position weights change. So I agree
> that it is not a great idea to include a graph of this number on
> the Metrics page.

I wonder if we can simplify the calculation somehow, so that we don't
have to worry (as much) that it will break in the future.  Hmm.

> The calculation of traffic fraction at relays only relied on (i) 
> rendezvous circuits being six hops (not a shaky assumption) and
> (ii) that the Metrics numbers for total network traffic was
> accurate (also seems like a good assumption). So it seems that we
> could include this number, although it is the less interesting of
> the two numbers.

True.  Let's keep this in mind as plan B.

>> By the way, I decided against using onion service terminology,
>> because I wasn't sure when we were planning to switch.  I'm not
>> sure if Metrics should be one of the first Tor websites to
>> switch, or whether people will just wonder what crazy
>> Tor-unrelated stuff Metrics has statistics for.  I don't feel
>> strongly though.  Thoughts?
> 
> You could use the new terminology, with a footnote on the page 
> explaining that "onion service" is the same as "hidden service".

I think I'd rather want to wait until documentation on Tor's website
and in tools is updated.

All the best,
Karsten

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJVAwHAAAoJEJD5dJfVqbCrdJsH/iUuCNMq/R/Yki015ZZ6i7+z
OfszriSwUsO4MNuAX7E3yHHlbd5ZDnPJbN+H65wSIrFz2Tu8i1OopORu4EfJLukN
9zpS+SSR0ZoQk4BP8bw0447b46V6GsCy14TLnxUvGBvA1qaYwZM7JKH+RIDkztN/
b1aHf1IxkH92LzxNex/bAkxU6+ivIrRUIC/+/hVa9F2K9FTEbMh1T1WrS9TAukPZ
kRW/wqk2wVXgZYV3Vur6bP+5gXOjvXiO5gpKzBv0wVlroCLgOI8idzF1JScQc2AA
vEoBr9iFF7JBgtCtnyg6GZNcZvqTIb1/cQ1e2xdYJLluX5UAveNExxC96bCl8lo=
=kE9g
-----END PGP SIGNATURE-----
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev