Re: [tor-talk] Tentative results of analysis of data on metrics.torproject.org

[Roger Dingledine <arma@xxxxxxx>]

On Wed, Sep 03, 2014 at 04:10:13PM -0700, Virgil Griffith wrote:
> https://docs.google.com/document/d/1SaBK664SchhZOP9XBsB8KK63k4xlmMTlkhfF28f2204/pub

Hi Virgil,

Neat analysis!

I think putting this up on the Tor blog, once it settles a bit, is a
fine plan.

You might also want to put it together as a Tor tech report, to go
with the other ones that Karsten has done, some of which are about
metrics data:
https://research.torproject.org/techreports.html

In the mean time, here are some thoughts:

- Figure 3 is a bit weird. Our bandwidth-per-relay stat is a function of
how many total relays we have, but not really a function of the growth
in total relays. So if for example we added a bunch of fast relays,
but we also added even more slow relays, then this graph would show
that bandwidth-per-relay isn't growing. So I guess the question is:
what conclusions should we draw from Figure 3? If it levels off or goes
down in the future, does that indicate a bad thing in any way?

Or said a different way, maybe we should be graphing the mean bandwidth
of the fastest k relays in the network? That's sort of what we had in
mind with
https://metrics.torproject.org/bandwidth.html#advbwdist-relay
and it better shows the growth in capacity of the network, in a way
that wouldn't be dragged down by adding a whole bunch of fast relays
(which people use) but also adding a whole bunch of slow ones (which
people don't use).

Which leads to: we want something that takes into account Tor's
"clients choose relays proportional to their bandwidth" load balancing.
From your transition text between Figure 3 and Figure 4 it looks
like you're trying to use bandwidth-per-relay as a stand-in for
expected-bandwidth-for-the-client, which I think it isn't because clients
don't select relays uniformly.

Also, it would appear that this Nielsen's law is about bandwidth that home
users get in one direction. I think that's probably quite different from
bandwidth that hosted servers get in both directions. Does Nielsen's law
say anything about upstream bandwidth? Did you bring it up just because
they both said 24 months, or am I missing the tie-in?

- When you say "Torperf speeds double" I get confused, because Torperf
primarily measures in seconds-to-fulfill-the-request, where lower is
better. Maybe you should avoid the word 'speed' and use either 'latency'
or 'throughput'?

(Several times you say 500 KiB when I think you mean 50 KiB?)

I think a lot of the explanation for Figure 5 comes from the fact that
Torperf mushes together two measurements -- first is the round-trip
involved in asking for the file, and second is receiving the cells that
make up the file. In the 50KB case it all fits in one flow control window,
so it really is just these two components (and we see the difference
clearly in the y-axes of your Figure 6b graphs). In the 1MB case that's
four or five congestion windows worth of cells, so it's again mushing
together round-trip times with throughput.

(Actually, let's think about that one more -- at 498 bytes of application
data per cell, and 500 cells per stream window, that's 249000 bytes per
stream window, so going through four stream windows means you've fetched
996000 bytes -- just shy of getting those last 9 data cells, and you then
have to wait for another round-trip! So I think one conclusion is that
our Torperf results for 1MB and 5MB are non-linear in quite subtle ways.)

So comparing our Torperf results to this Ookla data... which appears to
simply be throughput? If the round-trip latency does indeed play a bigger
role in Tor than it does on the normal Internet, then this comparison
might be apples to oranges. I wonder if there's a way, given the 50KB /
1MB / 5MB data, to separate out these two components?

- For your Figure 6a, there's a challenge here because the "number
of clients" graphs are the number of Tor clients running, not
the number of Tor clients clicking on something at once. Getting
a better handle on client behavior is an open research problem
(and Nick Hopper's lab at UMN is looking into exactly that:
https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorQ )
but some papers like http://freehaven.net/anonbib/#cset12-modeling tend
to consider the set of "active" clients in the tens of thousands range,
not the millions range. It sure would be neat to get a better handle on
the number of clients who are typically vying for bandwith at once --
I bet it's way less than 2 million.

Thanks!
--Roger

-- 
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk