19:33:48 <nickm> #startmeeting prop265,take1
19:33:48 <MeetBot> Meeting started Mon Feb 15 19:33:48 2016 UTC.  The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:33:48 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
19:34:09 <nickm> ok, so where does it all stand today?
19:35:28 <mikeperry> so teor and I had some mailinglist discussion. it doesn't change the equations, but using them for hidden service load will be a little tricky
19:35:29 <nickm> I wonder whether there might not be a simpler way to manage the equations here.  They've had a lot of tweaking in the past...
19:36:09 <mikeperry> the tweaking has been because of the subcases, which this proposal eliminates
19:36:26 <nickm> ah, neat
19:37:04 <nickm> under what circumstances would _these_ equation turn out to be wrong?
19:37:56 <mikeperry> mostly if we change how hidden service paths work, and their traffic starts to become a significant fraction of the tor network
19:40:13 <mikeperry> in the current load balancing equations, that is not accounted for at all
19:41:10 <mikeperry> in prop#265, we could represent it as overhead on Guard and Middle nodes
19:41:53 <mikeperry> exactly what that looks like will depend on the final form of prop#247, and if we make that a default or not
19:43:06 <nickm> I wonder if we can imagine some meta-system where we change parameters as path selection changes, rather than changing whole equations
19:43:18 <nickm> I can't think of one though
19:46:26 <nickm> mikeperry: so, I think I'm inclined to just say "yeah this is probably right".  What's the target time to deploy it?
19:47:30 <mikeperry> well, the good news is that as soon as the authorities upgrade to this, existing clients will just use it. it uses the same weight variables, just calculates them differently
19:48:32 <nickm> and if the main need for this is in reaction to padding, we should aim for 'soon'; this month, or early in the 029 cycle
19:48:40 <nickm> the latter would give us more breathing room
19:48:55 <nickm> question: do we have any metrics for the 'badness' of a particular weighting algorithm?
19:49:33 <mikeperry> do we expect the authorities to continue to run stable-tor, or do we think once we sort out all the ed25519 key transition that they will start running alpha/master again?
19:49:53 <nickm> I frankly do not know. I bet they could be persuaded to do master
19:50:51 <nickm> this is one area where it might be cool to know the difference between the current weights and the proposed ones.
19:51:11 <nickm> and how bad the current ones are if we stick with them for a month or two longer  than we want
19:51:13 <mikeperry> one metric is looking at the bandwidth authority ratios for different node flag classes
19:52:28 <nickm> how far off are we now?
19:52:56 <mikeperry> if the bandwidth authorities find that the Guard flagged nodes are being measured as much slower than middle and exit nodes, then that indicates we have a problem due to padding
19:53:30 <mikeperry> I think historically, middle nodes have gotten measured the slowest.. possible because we don't account for hidden service load now?
19:53:35 <mikeperry> let me see if my old scripts still work
19:56:09 <mikeperry> I need to turn of microdescriptors and fetch the full consensus for it to work. not sure how long that will take
19:58:52 <nickm> hm ok
19:58:56 <mikeperry> right now Guard+Exit nodes are the fastest nodes by far by class
19:59:01 <mikeperry> (it ran)
19:59:47 <mikeperry> Guard Avg Ratio: 1.91521379395
19:59:48 <mikeperry> Guard Ratios < 1: 8.6%
19:59:57 <mikeperry> Mid Avg Ratio: 0.743727325274
19:59:57 <mikeperry> Mid Ratios < 1: 73.2%
20:00:05 <mikeperry> Exit Avg Ratio: 0.815731742535
20:00:06 <mikeperry> Exit Ratios < 1: 73.3%
20:00:16 <mikeperry> Guard+Exit Avg Ratio: 1.83781167591
20:00:16 <mikeperry> Guard+Exit Ratios < 1: 18.7%
20:01:20 <mikeperry> so it seems as though we have lots of guard capacity, and we should be using guards more often in the middle position, and Guard+Exits in the Exit position
20:02:07 <mikeperry> (a ratio below 1.0 means slower than network average stream capacity.. a ratio above 1.0 means faster than network average stream capacity)
20:02:23 <nickm> and we seem to be off by something like 20% ?
20:02:36 <nickm> or rather
20:02:39 <nickm> um
20:02:44 <nickm> no
20:02:46 <mikeperry> ((so a ratio of 1.915 for Guard nodes means that nodes with the Guard flag have 1.915X faster stream capacity on average when you use them, as compared to the rest of the network)
20:03:09 <nickm> I think that means Guard+Exit Avg Ratio is very wrong, and  Guard Avg Ratio is very wrong, by nearly a factor of 2
20:03:27 <mikeperry> this is computed from the ancient statssplitter.py in the torflow repo, fwiw
20:04:18 <mikeperry> yeah, so without changing the load balancing equations at all, we should actually expect it to correct itself a bit
20:05:28 <nickm> this interacts with current torflow wonkiness, I bet?
20:05:38 <mikeperry> with padding, I mean
20:06:07 <nickm> ah
20:06:46 <nickm> So, anyway, I think this seems like a good idea to me and
20:06:51 <nickm> #action we should call this proposal accepted
20:08:09 <mikeperry> yay
20:08:10 <nickm> What's your preferrred implementation timeline?
20:08:31 <nickm> Mine is "early in 0.2.9, we already have crazy stuff happening between now and 028"
20:08:52 <mikeperry> I don't know. now that I am seeing the Guard flags actually being underloaded in the current system, it seems like there is not a lot of rush
20:09:05 <nickm> ok.
20:09:11 <mikeperry> yeah, we can watch the padding statisics come back from 0.2.8 first
20:09:33 <mikeperry> and see if the balancing according to the bw auths changes any
20:09:37 <nickm> #action nickm mark the proposal as accepted, target 029, and hope mike does a clean implementation :)
20:10:37 <mikeperry> I will do my best
20:11:33 <mikeperry> I'd be happiest if we could get regular metrics graphs for this load balancing stuff, and the new padding stats, but Karsten seems to think that will be painful, and its easier to do it ad-hoc instead
20:15:38 * mikeperry skims his Tor TODO list and moves this down into 0.2.9-land
20:17:36 <armadev> my tiny input here: it would be smart for more than just mike to understand his complex series of equations
20:17:38 <nickm> If you can move any tickets for this as well, that would be a good thing to do.
20:17:46 <armadev> in the past i just sort of figured he was smart so surely they were right
20:17:59 <armadev> a little voice in my head tells me that everybody else probably did too
20:18:34 <nickm> he says teor understands them too :)
20:18:45 <nickm> and a robot checked his algebra.
20:20:05 <mikeperry> two robots. I had a hippie robot and some dog-beast thing that kept rambling about a New Kind of Science
20:20:42 <GeKo> lol
20:21:44 <mikeperry> I tried to make the proposal easy to understand without having to wade through all of the old equations, too
20:22:08 <mikeperry> it is a very similar idea. it just simplifies the equations by making GuardExits only be treated as Exits
20:22:51 <mikeperry> and then once simplified, it adds in overhead parameters, which get a bit hairy, but you can spot-check that the equations are the same if the overhead parameters are zeroed
20:30:18 <armadev> the little voice in my head won't go away, but, great to hear!
20:30:34 <mikeperry> heh
20:30:51 <nickm> then endmeeting?
20:30:54 <nickm> #endmeeting