[tor-bugs] #6341 [Tor Relay]: connection_or_flush_from_first_active_circuit() does wrong thing when ewma_enabled

[Tor Bug Tracker & Wiki]

#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