16:00:56 #startmeeting SponsorR 16:00:56 Meeting started Tue May 19 16:00:56 2015 UTC. The chair is asn. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:56 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:01:04 hello friends. 16:01:09 hi everyone 16:01:19 so who is here? 16:01:23 me 16:01:29 no syversons or ohmygodels today. 16:01:36 but i think we have a full Tor house. 16:01:59 so let's start with status reports 16:02:04 i can start since i'm brief 16:02:28 during past week i was mainly doing exams and thesis. fortunately, the big load finished today. there is still more to come but that's in 7 days or so. 16:02:41 i talked with karsten adn dogulet about #15744 16:02:50 (which was just updated with graphs fromn what i see) 16:03:03 4 minutes ago! 16:03:04 and i also looked a bit at the new DoS #16052 16:03:29 also discussed with kernelcorn his SoP project. 16:03:34 anyway that's it from me. 16:03:36 who wants to follow? 16:03:57 karsten: go for it 16:03:57 well, I could. 16:04:04 (seems like dgoulet is missing, but it's ok) 16:04:08 https://people.torproject.org/~karsten/volatile/torperf-hs-on-ferrinii.png 16:04:15 * asn looks 16:04:24 we now have torperfs set up to measure hidden service performance. 16:04:35 they're running on ferrinii, a tor vm. 16:04:43 interesting 16:04:46 and this is on the real network 16:04:50 they're writing tor's logs to disk, which is not ideal. 16:04:55 yes, real network. 16:04:57 and they fetch every how many minutes? 16:05:19 51200 every 5 minutes, 1024*1024 every 30 minutes, 5*1024*1024 every hour. 16:05:33 right on 16:05:42 what do we hope to find from this? 16:05:43 so, I need to write some code to get these measurements onto metrics. 16:05:52 or just get a baseline? 16:05:57 baseline, I think. 16:06:04 of average bandwidth on hidden services? 16:06:07 wasn't this one of our milestones for april or may or june? 16:06:09 *of average bandwidth of clients on hidden services? 16:06:20 karsten: prossibly. 16:06:28 great. 16:06:37 so, this graph is just to show you that these measurements are happening. 16:06:40 ack 16:06:44 events contain lots of details that are not shown here, 16:06:47 right 16:06:53 including substeps of the connection establishment process. 16:07:18 so, my goal is to write that additional code to get these measurements archived and onto metrics in the next weeks. 16:07:29 great 16:07:31 so, that's one thing. 16:07:38 https://trac.torproject.org/projects/tor/ticket/15744#comment:12 is the other thing. 16:07:43 * asn looks 16:07:44 especially https://trac.torproject.org/projects/tor/attachment/ticket/15744/introduction-circuits-2015-05-19.pdf 16:08:03 I can include more data from dgoulet and others there. 16:08:36 useful. 16:08:47 yes, getting more data would help. 16:08:56 ok. 16:08:58 i will look at the graph and think some more of other visualiztions that we might want. 16:09:03 thanks :) 16:09:05 great! 16:09:08 that's all from me. 16:09:13 ack 16:09:22 ah, maybe one thing: 16:09:35 I learned that I'll have to spend quite some time fixing/migrating yatei soon. 16:09:38 because it's dying. 16:09:47 Yawning: yes, so can chain .tor to .tor, which is quite powerful. I"m aware of loops, I have not yet addressed that 16:09:54 I shouldn't commit to doing more R things this week, I think. 16:10:00 karsten: ok 16:10:03 karsten: no worries 16:10:16 if there is something *urgent* i wll tell you -- but i don't expect it to be 16:10:21 cool! 16:10:26 so brief meeting today 16:10:29 do we want to talk about something? 16:10:32 kernelcorn: ok 16:10:36 i haven't had time to think much of sponsorr the past week 16:10:55 but it seems like we are on track (?) 16:11:17 I have no idea, to be honest. are we? 16:11:24 we are doing things. 16:11:25 Yawning: also, if I control a.tor, I automatically have control over b.a.tor and c.b.a.tor, and so on. 16:11:42 karsten: i feel we are OK in terms of statistics for July. 16:11:49 karsten: with #15744 and #15513 16:11:50 ok, great! 16:12:03 (and i have more data that we can graph on #15513, but i will wait to gather more till june) 16:12:24 ah, that one. cool. 16:12:27 karsten: and i think dgoulet is going strong with his hsdir health. 16:12:31 so i would say we are ok. 16:12:39 i can speak some more with dgoulet about hsdir health later. 16:12:52 sounds good! 16:12:55 karsten: did you see anything interesting on the graphs you made? 16:13:21 well, 80% of introduction circuits not being used at all was surprising. 16:13:54 and 5% having a lifetime over 25 hours. 16:14:01 is that 80% or 90%? 16:14:04 looking at the first graph 16:14:08 it's hard to distinguish between 0and 1 16:14:17 I'm here! 16:14:25 hi dgoulet 16:14:32 so sorry was eating lunch and forgot about the new time :( 16:14:37 dgoulet: hello. prepare your status report and we will be with you in a sec. 16:14:38 dgoulet: no worries. 16:14:41 asn: you mean 0 vs. 50? 16:14:52 karsten: yes correct. 16:14:57 0 or 1-50 16:15:04 ok 16:15:07 that answered my question i guess 16:15:12 0 is from 0% to 80%, 1-50 to 90%. 16:16:23 ack 16:16:28 now it makes sense 16:16:45 i think also a simple histogram might be useful in this case. 16:17:11 but anyway, i will look into the graphs more later. 16:17:14 dgoulet: whatsup? 16:17:15 for a presentation? 16:17:34 ok 16:17:41 Working on little-t tor SponsorR patches, most of them in need_review. HS Health improvement, I pushed a design doc (not amazing but a start) mostly made from my notes I wrote down on paper. 16:17:46 Turns out the hs-health is detecting misbehaving HSDir as a side effect :). I've reported two of them on bad-relays@ last week. It's getting more and more stable so next step is definitely try to come up with useful visualization using the logs. 16:18:01 (asn: talking about graphs on the ticket sounds fine.) 16:18:06 karsten: ack 16:18:10 I might need karsten graph experience for that 16:18:11 dgoulet: where can we find the design doc? 16:18:17 on the git repo 16:18:20 ok 16:18:29 https://gitlab.com/hs-health/hs-health/blob/master/design.md 16:18:35 dgoulet: sure, just let me know what you need. 16:18:38 ack 16:18:43 oh wow, not in gitweb.tpo. 16:18:44 will improve it, some small features and future works are missing 16:18:50 dgoulet: ok 16:18:57 btw, sorry for not remembering, 16:19:06 but did the hshealth thing produce graphs in the past? 16:19:11 will it produce graphs for july? 16:19:16 * asn is all about those graphs 16:19:20 this is turning into something bigger and bigger so before it gets to ugly code wise and feature wise, I need to take a step back and come up with a better design doc. 16:19:27 dgoulet: ack 16:19:50 no the graph that were produce in the past are the tracing analysis, different 16:20:09 i wouldn't go overboards with super clean architecture and stuff. but yeah, making it less ugly is definitely good. 16:20:26 hoverboards 16:20:44 clean design is good. 16:20:45 imo, we can definitely graph "churn effect over time" that is when it happens and how much time it takes to recover 16:20:52 you might have to maintain it for years.. 16:20:57 karsten: exactly 16:21:10 dgoulet: churn effect of what? 16:21:11 it's pretty useful and I would like to integrate in the long run DonnchaC bad hsdir detection 16:21:20 dgoulet: hs descriptors? 16:21:25 * isabela around 16:21:28 asn: when a HSDir is getting replaced by an other one for a desc ID 16:21:31 sorry reading backlog 16:21:50 asn: there is a delay before the descriptor shows up on the new HSDir because of different consensus on the HS and client 16:22:33 aha 16:23:07 ok will be cehcking the design doc soon hopefully 16:23:42 I want to send karsten the logs it has and see how we can visualize some of it 16:23:57 dgoulet: please do. 16:23:57 feel free to cc me 16:24:08 * DonnchaC checks it out 16:24:09 FYI, to run this tool you need upstream master, stuff that the tool needs has been added very recently 16:24:55 * dgoulet done report 16:24:57 (I guess I did R stuff >.>) 16:25:00 thx 16:25:06 dgoulet: do you have anythig you want to discuss? 16:25:07 (#16052 is R right?) 16:25:25 Yawning: maybe. it's more SponsorU i think 16:25:32 oh ok 16:25:35 yes I do have something to discuss 16:25:41 *wanders off* 16:25:49 Yawning: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorU/Tor 16:25:54 Yawning: sponsoru seems to be the DoS one. 16:25:59 dgoulet: bring it on 16:26:01 (let me know if you want my help for this -> we should figure out a plan to brainstorm the Right Guard Behavior this month. 16:27:02 we need a 0.2.6 release because of #15801, HS health tool is seeing more and more timeout on HSDir on the first and second try, I had report from HS op (quite used one) that people are complaining more of rechability issue lately 16:27:11 so I don't know if it's ^ specifically 16:27:26 nickm: ^ 16:27:35 but right now it's pretty common that we have a .onion that has one or two valid HSDir only 16:27:39 should I work faster on this mitigation hack? 16:27:47 so we can include a backport as well? 16:27:56 and my guard is starting to show signs of stress with more and more warnings (the one running hs-health) 16:28:22 dgoulet: what does the guard have to do with this? 16:28:48 anybody want to help with the next 026 release then? 16:28:55 nickm: what needs to be done? 16:29:08 see the release checklist in doc/HACKING? 16:29:21 is there anything there that could be done by a non-nickm? :) 16:29:28 (I shall take that as a no) 16:29:34 asn: I don,t know, it's just something I've seen lately, maybe too many hsdir requests or ... we have .onion right now that have only one HSDir with like 80kb/s bw... so means everything goes there ... 16:30:03 thus I think we might want to merge the "is_stable" patch for HSDir flag also in 0.2.6? 16:30:27 nickm: changelog could be curated by non-nickm 16:30:37 nickm: and testing i guess 16:30:49 and maybe #15963 also 16:30:53 testing would rock; I can do the changelog pretty fast for this one 16:31:17 fixed "bugs" 16:31:23 ok i will try to give it a bit of testing today or tomorrow. 16:31:25 *ducks* *runs* *hides* 16:32:06 I also have another topic I would like to discuss 16:33:12 * dgoulet waiting for the current topic to be set and close :) 16:34:07 dgoulet: maybe previous topic is closed now 16:34:28 yeah ok 16:34:31 with "nickm will try to release next 026 soon. need help in testing" 16:34:40 good 16:34:46 dgoulet: are you saying that there are patches not merged in 026, that you want in the next realese? 16:35:02 Stable for HSDir 16:35:07 I think isn't merged 16:35:10 #8243? 16:35:14 ok 16:35:18 yeah this ^ 16:35:23 and maybe #15963? 16:35:33 ok will try to look soon 16:35:40 I would like as little backported as possible 16:35:53 and only things with a lot of testing 16:35:59 please keep that in mind? 16:36:00 I stand by my rationale for #8243, but 16:36:43 dgoulet: #8243 and #15963 are not as urgent as #15801, right? 16:36:50 they are just "would be nice if they were in" 16:36:51 15801 is already merged 16:36:51 or not? 16:36:55 yes 16:36:56 well 15850 sorry 16:37:31 yeah but Yawning has a rationale for #8243 to be merged in 0.2.6 so "should be consider" is what I would say 16:37:39 I think changes to the voting there should happen in the 0.2.6.x timeframe, but I don't view it as urgent 16:37:57 like, not "oh my god there's only 1 HSDir for foo.onion" sort of urgent anyway 16:38:08 ack that's what i think too 16:38:15 dgoulet: next topic? 16:38:16 makes sense 16:38:18 ok next topic 16:38:20 * asn needs a break 16:38:27 (will be fast) 16:39:17 can somebody put all that sutff in an email to me? 16:39:37 actually nvm, nothing important now :P sorry 16:39:42 nickm: i can do so 16:39:56 except if dgoulet wants to, since he knows these tickets better currently. 16:40:34 dgoulet: you sure? ask away if you want! 16:40:39 well it's pretty easy, if we think #8243 can wait, well 0.2.6 branch is ready for a release 16:41:00 right 16:41:01 and DirAuth must deploy it :) 16:41:08 else no point of a release :) 16:41:13 imo let the changes bake a bit, also do the fast thing, and do it next release? 16:41:18 when things aren't quite as on fire? 16:41:42 Yawning: you mean do #8243 and fast thing on next release? 16:41:44 i'm fine with this. 16:41:47 yah 16:41:49 +1 16:41:50 ok 16:42:13 in that case, we just need a 026 release. and work on #8243 and fast thing soon, so that it's ready for next release. 16:42:19 that simplkifies things. 16:42:20 yes 16:42:35 right on 16:42:39 (my rationale for deploying them in a stable branch is correct right?) 16:42:56 ok cool 16:43:29 Yawning: you mean so that dirauths can deploy them eaiser? 16:43:32 makes sense 16:43:35 yah 16:43:38 ok i guess this sums it up 16:43:42 i will send a brief email to nick 16:43:49 with the summary of what we jsut said 16:44:04 awesome 16:44:17 ok thanks for the meeting guys 16:44:24 thanks all 16:44:25 i will take a small break now, and be back in an hour or so. 16:44:30 thanks! 16:44:31 i will be around irc this week. 16:44:33 thanks! 16:44:39 so i will be easier to reach :) 16:44:40 take it easy! 16:44:41 you guys got my email about this week right? 16:44:42 #endmeeting