[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-dev] Progress on hidserv-stats Metrics integration, request for code review
-----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