[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #6341 [Tor Relay]: connection_or_flush_from_first_active_circuit() does wrong thing when ewma_enabled
#6341: connection_or_flush_from_first_active_circuit() does wrong thing when
ewma_enabled
-----------------------+----------------------------------------------------
Reporter: arma | Owner:
Type: defect | Status: needs_review
Priority: normal | Milestone: Tor: 0.2.3.x-final
Component: Tor Relay | Version:
Keywords: | Parent:
Points: | Actualpoints:
-----------------------+----------------------------------------------------
Comment(by robgjansen):
Replying to [comment:31 arma]:
> I'm increasingly thinking that the Shadow client model, when doing
performance comparison tests, should be "each client fetches a set number
of things."
>
> That way the total load on the network is fixed between comparisons, and
the only question is "how well does the network handle this set of users
doing that set of activities?"
It may be worth considering a model like this, if nothing else because we
haven't given it much attention so far and we may be able to learn
something we otherwise would not.
>
> I don't deny that it's interesting to consider the "if it works better,
they'll use it more, putting more total load on it" dynamism.
>
> But the current client model makes it hard to say things like "clients
in both cases fetched all 100 of the files, but in case 1 they got their
files faster on average" and "clients in case 1 successfully fetched fewer
of their files".
There is no panacea.
In your new client model, the network may start out looking like a Tor
network we think we understand, but the network will slowly transform into
something entirely different as more and more clients finish their set
number of downloads. By the time 99% of the clients finish, I'd argue that
we are so far from any real Tor network in terms of load, congestion, etc,
that the results are no longer meaningful. And I'd guess the efficiency of
the network probably doesn't scale linearly with the load either, meaning
we may get a skewed impression of how things are working. In our current
model, and assuming no software bugs, any given download will occur on a
'properly' loaded Tor network (for various definitions of 'properly').
RE the questions you stated above: perhaps we should be analyzing the data
slightly differently than we have been? Instead of aggregating all the
client download times into one CDF, would it help to look per-client
details: e.g., how many downloads each client finished and what the
download times were for each client, etc. (I'm thinking of an average and
a 5 number summary for these, but you could also draw a CDF for each
client;) But you're right, we won't be able to say "he was supposed to
download X things, and he finished in Y seconds" when there is no fixed X.
>
> If we want to get fancy, we could have the web browsing users fetch a
set number of things, and the filesharers just keep downloading. Lots of
permutations, each of which expose some properties and brush others under
the rugs. Hm.
Yeah, I think we want a hybrid here: something like our current model to
produce the background traffic that we think is characteristic of a real
Tor network, with the addition of some other clients that have a
deterministic set of downloads to perform. I guess this is somewhat
similar to Tor+TorPerf. In fact, we have already built in TorPerf-like
clients into our model, so it may be worth analyzing their data
separately.
Or course it would help if we could be sure all the clients could download
successfully through their SOCKS connection;) We're still working on that.
Wheeee.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/6341#comment:32>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs