13:30:06 <nickm> #startmeeting 13:30:06 <MeetBot> Meeting started Wed Oct 1 13:30:06 2014 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:30:06 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic. 13:30:15 <nickm> It's that time again -- time for another fun-filled tor meeting 13:30:17 <nickm> who's about? 13:30:27 <athena> hi nickm 13:30:51 <nickm> hi athena 13:31:38 <dgoulet> hello meeting 13:32:03 <nickm> hello dgoulet 13:32:09 <nickm> anyone else? I've seen Yawning ... 13:32:11 <athena> latest (-Werror clean) version of the sheduler is in my cmux_refactor_for_026_squashed_2 branch 13:32:28 <nickm> athena: neat. I've been reading it and I hope Yawning has too 13:32:40 <nickm> athena: have you looked at rob's experimental results that he asked about? 13:33:09 <nickm> (See #12889) 13:34:32 * athena looks at #12889 13:34:54 <Yawning> <- here, sorry was getting a soda 13:34:59 <nickm> np 13:35:06 <nickm> that reminds me, my tea should be ready soon 13:35:08 <nickm> 30 sec 13:35:22 * dgoulet go grab the coffee :) 13:35:24 <athena> hmm, i'm curious whether the choice of the global high/low-water marks is a bandwidth/latency tradeoff now 13:35:47 <nickm> back now 13:37:10 <nickm> I wonder what we should suggest that Rob try next 13:37:46 <nickm> And how we can find out if this is a bug, or as-intended, or what 13:39:39 <athena> the most interesting thing that comes to mind is varying the thresholds 13:40:15 <athena> in particular, in the limit of very high thresholds the behavior should converge to something like the old behavior, modulo maybe a little higher latency for triggering the new mechanism through libevent and all 13:41:37 <athena> if the gap persists even when the global high/low water marks are set so high we start sending as soon as a circuit has anything to send, we're basically scheduling one circuit at a time like without the global scheduler 13:42:51 <Yawning> hmm 13:43:07 <nickm> there's also the possibility that something is going on we don't expect. I wonder how we can figure out which. 13:43:21 <nickm> and/or confirm your hypotheses above 13:43:29 <Yawning> run the case athena just suggested and see if the behavior is what we expect? 13:43:38 <nickm> hm. Plausible. 13:43:51 <nickm> Anybody want to write this up on #12889 ? 13:44:04 <athena> i will 13:44:07 <nickm> thank you 13:44:16 <nickm> got anything else going on? 13:46:28 <athena> if we're going to be experimenting around and tweaking and thus not merging the global scheduler any time very soon, iwant to cherry-pick out some of the unit tests for it - they cover a lot, e.g., channel.c 13:46:44 <athena> and do you think it's time to do some more triage? 13:47:08 <nickm> both ideas sound good. I think it might be a good idea to try to fix bugs and review code before we get back to triage. 13:47:15 <nickm> But a little wouldn't hurt I guess 13:49:08 <nickm> got any triage in mind? Want to do some after the meeting? 13:49:29 <nickm> right now I'm enmeshed in the thing I'm goign to talk about once I'm talking aout things :) 13:50:16 <nickm> Yawning / dgoulet : Would you like to go? 13:50:24 <athena> right now i'm close to the end of my period-of-wakefulness, so my utility for that might be limited right now 13:50:47 <athena> i'm all up for finding some bugs to fix and worrying about triage next week if you want 13:51:06 <nickm> That sounds good to me. 13:51:11 <nickm> Or implementing features we need 13:51:19 <Yawning> for tor all I did was review stuff, and that tor-resolve thing 13:51:34 <nickm> athena: I think we've got enough stuff we know we need to do to keep us busy for a week at least 13:51:59 <athena> okay 13:52:01 <Yawning> poking at our socks implementation atm (#13314), and I have a date with nick to review #9262 (tomorrow) 13:52:40 <Yawning> and I'm wirting the ticket on fixing our fqdn validation in said socks code, after making sure my memory of how IDN works is correct 13:55:50 <nickm> Sounds useful 13:56:11 <nickm> I'm trying to review a bunch of code, merge as much stuff as I can, and work on ed25519 stuff. 13:56:38 <nickm> I have the certificate-making, certificate-checking, key-storing, descriptor-signing, and descriptor-checking parts of 220 done 13:56:46 <nickm> I hope I can finish the rest soon. 13:56:53 <nickm> There's a lot of stuff there 13:57:46 <nickm> Also I'm going to try to get #9262 reviewed again, and get somebody to look at my ed25519 code, and figure out how to make stegotorus code-reviewable 13:58:10 <nickm> and there is supposed to be a master schedule. I should figure out why I can always find something else to do besides that 14:00:44 <nickm> the prop220 diff is ~4000 lines already :/ 14:00:51 <nickm> fortunately, there are lots of tests 14:01:04 * Yawning files #13315 14:01:10 <nickm> thanks 14:01:21 <Yawning> np, I'll probably just fix it tbh 14:01:46 <nickm> thanks 14:01:49 <nickm> dgoulet: anything going on? 14:02:22 <dgoulet> so unfortunately, on the Tor side not much, I'm working a lot! lately to transition to Tor full time, official date is November 1st but I'm hoping a bit before 14:02:37 <nickm> that would be nifty 14:02:37 <dgoulet> however, this page contains quite some ticket about HS that I might start tackling 14:02:40 <dgoulet> https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorR 14:02:51 <nickm> we should schedule your visit to boston, btw. 14:03:02 <dgoulet> nickm: yes! replying to that email today :) 14:03:15 <nickm> please let me know about that so we can settle on dates, so I can answer the other folks who want to schedule stuff with me :) 14:03:18 <nickm> greate 14:03:20 <nickm> *great 14:03:31 <asn> what are the possible dates approx? 14:03:43 <asn> to see if they are in any way compatible with my uni schedule 14:03:49 <dgoulet> the tickets on the sponsorR page, some hints on the useful one would be cool (and also some that I could tackle with my current knowledge) :) 14:04:07 <dgoulet> asn: we were talking about November except a couple of dates 14:04:24 <asn> i see 14:05:33 <dgoulet> asn: also continuing on SponsorR things, maybe it would be a good idea if we sync at some point to schedule stuff between us? 14:05:43 <asn> yes 14:05:53 <asn> i'm trying to get this guardienss thing out of the way 14:05:58 <asn> so that I can focus more on HS stuff 14:06:08 <asn> when do you start work, btw? 14:06:33 <dgoulet> asn: officially nov 1st, but I want before and I think I might be able to make it work meaning maybe the third week of october 14:06:40 <asn> ack 14:07:05 <dgoulet> but we can start planning and I can poke around in my free time so just ping me when you are out of the Guard world :) 14:07:24 <asn> i will probably ping you before that. 14:07:30 <dgoulet> superb 14:07:32 <asn> btw, is there a SponsorR deliverable list somewhere? 14:07:51 <dgoulet> asn: what I have is basically the 17 pages proposal sent to them and the wiki page 14:07:59 <asn> right 14:08:46 <asn> so I guess we need to deliverablize the wiki page. 14:08:50 <asn> at some point. 14:08:54 <asn> so that we have concrete tasks in mind 14:09:01 <asn> and also see if we can sneak in any next gen hs projects in there. 14:09:02 <dgoulet> yeah, pretty broad stuff now but we can make it in concrete task 14:09:09 <dgoulet> asn: exactly! :) 14:09:19 <dgoulet> my understanding 14:09:29 <asn> i think that nick was planning on sneaking in some next gen HSDir stuff (the blinding stuff maybe) 14:09:36 <asn> judgign by the dev meeting roadmap 14:10:05 <dgoulet> yeah, well to quote the armadev, Focus on making useful things :) 14:10:30 <nickm> so, next gen HS stuff makes many measurements safer to conduct, and makes the code more tested and reliable. 14:10:36 <nickm> That speaks to sponsors S and R IMO 14:11:05 <dgoulet> yup, if next gen gets in the category of "improve reachability and reliability", it makes sense to tackle it I guess 14:11:54 <dgoulet> so yeah, that's it for my status update :) 14:12:07 <nickm> cool 14:12:11 <nickm> anybody else? asn? 14:12:23 <asn> me 14:12:26 <asn> just a sec 14:13:45 <asn> nickm: here is a small preview of the little-t-tor guardiness stuff: 14:13:48 <asn> https://pastee.org/u6x75 14:13:58 <asn> ^ this is how updating the total bandwidth weights might happen using guardiness 14:14:17 <asn> see the new update_total_bandwidth_weights() function. and how it uses the guard_get_guardiness_bandwidth() function. 14:14:28 <asn> the guard_get_guardiness_bandwidth() function is the main API to guardiness bandwidths 14:14:35 <asn> (all func names etc. are subject to change) 14:15:06 <asn> nickm: if pastebins are not your prefered way for doing this, I can post them in a branch. but I wanted something small and fast to show you during the meeting. 14:15:24 <asn> and then there is: https://pastee.org/5fhbb 14:15:34 <asn> which changes compute_weighted_bandwidths() to use guardiness info. 14:15:40 <asn> again the guard_get_guardiness_bandwidth() is used. 14:16:01 <asn> i have unittests for guard_get_guardiness_bandwidth(). 14:16:29 <asn> nickm: just wanted to show you how the code might look like ,and how the guardiness API might get implemented. 14:16:41 <asn> (Basically, you give it a router and its guardiness value, and it returns its bandwidth as a guard and its bandwidth as a non guard) 14:17:01 <nickm> do we ever want both at once? 14:17:24 <asn> yes: 14:17:25 <asn> + final_weight = 14:17:27 <asn> + guardiness_bw->guard_bw * weight + guardiness_bw->non_guard_bw * weight_without_guard_flag; 14:17:40 <asn> from https://pastee.org/5fhbb 14:17:58 <asn> as the prop236 says: 14:18:00 <asn> Let Wpf denote the weight from the 'bandwidth-weights' line a 14:18:00 <asn> client would apply to N for position p if it had the guard 14:18:00 <asn> flag, Wpn the weight if it did not have the guard flag, and B the 14:18:00 <asn> measured bandwidth of N in the consensus. Then instead of choosing 14:18:03 <asn> N for position p proportionally to Wpf*B or Wpn*B, clients should 14:18:05 <asn> choose N proportionally to F*Wpf*B + (1-F)*Wpn*B. 14:18:37 <asn> or, to compute total bandwidth weights (T/M/G/E etc.): 14:18:38 <asn> + *D += default_bandwidth; 14:18:38 <asn> + if (rs->has_guardiness) { 14:18:38 <asn> + *E += guardiness_bandwidth; 14:18:39 <asn> + } 14:18:48 <asn> from https://pastee.org/u6x75 14:18:56 <nickm> So weight_without_guard_flag == 1.0 - weight ? 14:19:05 <nickm> What's F and what's 1-F ? 14:19:10 <nickm> (in the code) 14:19:34 <asn> that calculation is done in guard_get_guardiness_bandwidth(): 14:19:38 <asn> + guardiness_bw->guard_bw = (int) (guardiness_fraction * orig_bandwidth); 14:19:38 <asn> + guardiness_bw->non_guard_bw = (int) ((1 - guardiness_fraction) * orig_bandwidth); 14:19:54 <nickm> ah 14:19:56 <asn> so basically, guard_bw is F*B, and non_guard_bw is (1-F)*B 14:20:14 <nickm> ok. I was missing that invariant. 14:20:39 <nickm> generally I'd suggest more comments that link this back to the formulas it's trying to implement and explain why it works this way, plus especially comments that document the invariants in the code 14:20:44 <asn> (i'm using associativity of multiuplication there.) 14:20:53 <asn> nickm: ah, ok. 14:21:33 <asn> ok, I will try to improve the comment quality and make it more easily to bounce between the spec and the code. 14:21:41 <nickm> cool. anyone else for the meeting? anything else for the meeting? 14:21:57 <asn> btw, which invariant were you referrign to? 14:22:14 <nickm> guard_bw + non_guard_bw == orig_bw 14:22:19 <asn> ah ok 14:22:32 <nickm> #endmeeting