17:00:22 #startmeeting weekly network team meeting 17:00:22 Meeting started Mon Feb 27 17:00:22 2017 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:22 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:00:24 hi all! 17:00:44 hi ahf, teor (!), isis, isabela (?), asn, dgoulet! 17:00:45 hii 17:00:51 hi 17:00:57 hello 17:01:18 hi 17:01:34 let's do status reports! who wants to start? 17:01:42 i can go 17:01:53 go for it! 17:01:54 Hello. I've finished the bench tool for different compression algorithms (can be found at https://gitlab.com/ahf/tor-sponsor4-compression/tree/master/bench and results at https://docs.google.com/spreadsheets/d/1devQlUOzMPStqUl9mPawFWP99xSsRM8xWv7DNcqjFdo/edit#gid=0 ), looked at Nick's analysis of the consensus modifications that will make consensus diff's smaller + his new specs sent to tor-dev, finished the 17:02:00 scripts for running our tests in #21205, which 17:02:03 have run for a bit over a week tomorrow, read up on torgzip.c, directory.c and continued with http://hapy.0x90.dk/~ahf/tor/xxx-directory-compression-scheme-negotiation.txt, got my head around how the directory authorities work from dir-spec.txt, and some administrative stuff with contracts/AMS meeting. Done. 17:02:08 there 17:02:27 Hello all ! 17:02:30 cool. Think we can get that proposal finished this week? 17:02:32 haxxpop: hi! 17:02:48 nickm: yes, i think it will be done by tomorrow noon 17:02:52 excellent 17:02:52 for review 17:03:16 and then we should discuss the results of the analysis for #21205 17:03:28 I'm currently working on the responsible hsdir picking function for prop224 17:03:43 ahf: yes. and probably decide which proposals to implement, and other areas of https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/Sponsor4Design to look at 17:03:50 nickm: yep 17:03:51 haxxpop: cool! 17:03:56 who's next? 17:03:58 i can go! 17:03:59 Hello, I spent a good part of last week being sick, but then I recuperated and 17:03:59 I spent the weekend hacking on the HS ntor handshake. I also reviewed a few 17:03:59 needs_review tickets. This week I plan to finalize the ntor branch, do some 17:03:59 review, and move to the next step of prop224. Next? EOF. 17:04:35 I did some things with chutney. If it had versions, it would probably be worth a major release. 17:04:46 teor: you could give it versions :) 17:05:09 It now tells you when tor has warnings, and works with relative paths, and has a few new options and bugfixes. 17:05:16 asn: the ntor thing is the "ntor with extra information" thing we're using to include RP info? 17:05:47 exactly 17:05:53 is the RP is being put into the hash of the state? 17:05:55 cool 17:06:02 nickm: I was hoping someone else would give chutney versions 17:06:17 isis: what do you mean "hash of the state"? 17:06:33 but no i dont think so. 17:06:41 isis: should it? 17:06:49 it's proposal 224, section 3.3.2 17:07:58 asn: i mean the `auth_input` part 17:08:14 isis: I think it isn't. 17:08:25 but now would be the best time to fix that, if it should be 17:08:41 yeah, it's not there. 17:08:44 what do we gain by putting it? 17:09:02 in theory it should be possible to put it tthere since both parties know the RP node by then 17:09:14 idk, i was just wondering where the RP info would go 17:09:46 i'm not sure what you'd gain by putting it there specifically, i'd need coffee to figure that out 17:10:02 it couldn't _hurt_... 17:10:08 * dgoulet can status update 17:10:12 go for it! 17:10:18 Last week was too little code and too much email backlog... I did some review for review-group-16 which so far seems to have been merged (yay!). I continued working on the circuit creation and logic of #20657 which is going well. 17:10:23 I took a day of Torsocks works also to kill some tickets and I'm just waiting a bit to see if something broke. I'll release a new version very soon. 17:10:26 I'm now back (this week) deep in prop224 implementation and will be able to make great progress with asn's ntor work. I'm confident that I'll have a "ready implementation (tm)" before Amsterdam! for which I hope to go at least with asn over the design choices and interface. 17:10:28 --- 17:10:45 (not very exciting but yeah that prop224 thing is basically my life now, I've accepted it :P) 17:11:18 ok, I think that leaves isis and me? 17:11:23 want to go, isis? 17:11:28 sure 17:11:28 I am here too 17:11:32 hi mikeperry ! 17:11:35 mikeperry: o/ 17:12:23 (I can go after isis) 17:12:27 last week i reviewed and merged in decaf code for ed25519, almost finished a cleanroom elligator implementation, and worked on the spec i'm supposed to be writing 17:12:39 sorry, decaf? 17:12:48 and which spec? 17:12:52 I have no long-term memory? 17:12:59 s/memory\?/memory/ 17:13:12 decaf is a point compression scheme which gets rid of the curve cofactor 17:13:36 making it easier to actually implement crypto that starts off with "take a prime-order group G..." 17:14:17 but it was designed for ed448 so there were some glitches getting it written for curve25519 17:14:25 Is the meeting in Amsterdam an annual meeting ? You organize it once a year, right ? 17:14:38 (this is for the credentials for the bridge distribution thing) 17:14:53 haxxpop: we do two meetings a year, in different places. We do one or two public days at each meeting 17:15:21 isis: cool 17:15:25 the spec is that i'm supposed to write down how the rbridge modifications work 17:15:26 thanks for explaining 17:15:34 nickm, nice! 17:15:45 mikeperry: your turn? 17:15:49 I am working on subprotocol versioning for Prop#254, and still trying to get a 17:15:50 isis: does that go to tor-dev when you're done? I'm looking forward to reading it, if I understand it 17:15:51 research team together to study it. 17:16:07 nickm: yes, of course! 17:16:09 Sorry I've generally been heads down on this and not participating much with other team stuff, but I kinda need a problem to rabbithole by myself on right now. 17:16:10 great 17:16:30 the branch for my netflow stuff was just rebased to 0.3.0 also 17:16:36 mikeperry: i know that marc juarez and giovani cherubin are coming for parts of the dev meeting, so they seem like a plausible research team 17:16:46 mikeperry: ok. BTW, I have been hassling Roger to get back to us on that thread. Have you had time to write the spec for the new cell types in the netflow branch? 17:16:56 (and whatever else doesn't match the proposal) 17:17:11 asn: yeah. I'm on an email thread with them, but they are busy and haven't committed yet 17:17:56 nickm: there already was a spec in there that both of us forgot. it is actually matching the implementation already. I have some partial fixes to the proposal to mak ethat match, too 17:18:19 okay, great 17:18:55 So, I spend last week with my family and inlaws, so I only had time to do a bit of stuff. 17:19:11 I wrote changelogs for the upcoming stable releases (they still need sorting), 17:19:17 tried to fix all my open 030 issues 17:19:43 wrote some proposals for sponsor4 (using less directory bw) 17:20:00 and did some measurements and experiments to back those proposals and quantify whether they'd help 17:20:32 This week I'm hoping to finish releases for 024 through 030, review all the pending needs_review stuff that I'm reviewer on, 17:20:56 and nail down open proposal questions for sponsor4 17:21:01 and have a hard look at prop#140 17:21:21 buzy 17:21:29 yah 17:21:33 (I was about to say something similar :) 17:21:36 maybe I'll get to program too :) 17:21:44 When it comes time to try the bandwidth proposals, we can deploy them on the test network 17:21:52 +1 ^ 17:22:00 oh, that will be fun 17:22:02 oh, one more thing I did: 17:22:07 mikeperry: same for your branch if you want a testbed 17:22:31 This morning I marked a bunch of proposals as "Finished", meaning that I believe they're implemented but not actually merged into the specs 17:22:50 I'd like us to get them all merged into the specs; things shouldn't sit in "Finished". 17:22:54 we're up to 18 17:23:09 +1 on testing mike's netflow branch on the test net 17:23:35 nickm: what is that ticket? 17:23:36 dgoulet: ok. yes, I will be wanting that in another week or two 17:23:48 #21554 17:24:08 ok 17:24:11 probably means we need another bandwidth authority on that network 17:24:26 teor: I can probably run one when the time comes 17:24:34 We should probably split them up; it seems too much for one person to do in a reasonable timeframe 17:24:37 teor: but if we might need more relays, making a call for help now would be wise 17:24:47 nickm: right I was thinking that, maybe a branch per proposal basically 17:25:21 also, I don't guarantee that they're all actually implemented as written, so it might be best if whoever implemented each either helps, or does the merge, or reviews. 17:25:34 dgoulet: it would be nice to have a multiple of the number of authorities 17:25:56 Anybody want to open subtickets for #21554 ? 17:26:21 nickm: I say once someone pick one proposal for merge, open a ticket as that one for parent? 17:26:29 ok, makes sense. 17:26:38 nickm: because quick look at the list, I don,t think they all need action item, we'll see 17:27:02 If some of them don't need any spec changes, we should call them "closed" 17:27:16 ah true ok so yeah ticket for each ahah 17:27:39 i can open a ticket for merging parts of prop#220 and #228 17:27:39 so, any other discussion topics this week? 17:28:17 teor: yeah atlas shows me 12 relays... we used to have a bit more but they might be down or something 17:28:19 mikeperry: btw, did you see my request earlier this morning about feedback on prop#276 ? 17:28:36 no I didn't. thanks for flagging. where did you ask? 17:28:41 this channel 17:28:54 teor: oh my and missing one dirauth and two have bad sig :P... 17:29:01 basically, ISTR that you disliked an earlier version of that idea, and I wanted to make sure you saw this one. 17:29:02 teor: some maintainance is needed :) 17:29:12 patrickod gave me patches for #16670 and #10227, and mentioned that it was difficult to figure out various things about the ecc keys because they were spread out between specs and proposals 17:29:40 so that should probably go into torspec or dirspec 17:29:42 isis: yeah; I think they should get easier once prop#220 is merged? 17:29:54 yep 17:29:56 dgoulet: we should have a meeting at the meeting 17:30:08 nickm: were you planning to merge the spec at the same time? 17:30:19 nickm: I believe teor did an alternate version of 210 while working on the directory mirrors? he used a different backoff algorithm, but a similar retry idea, IIRC 17:30:27 I'm not sure if he tried in parallel though 17:30:43 mikeperry: oh! I thought I had marked that one. 17:31:10 teor, mikeperry: so, call it "finished" or "superseded" or ... ? 17:31:18 isis: how do you mean "merge the spec"? 17:31:39 isis: I was planning on updating the spec to include the implemented parts of prop220, and then mark prop220 "closed" ? 17:32:21 yep, sorry, that's what i meant 17:32:28 ok, cool 17:32:41 as it stands, the network-protocol parts of 0.3.0.x are (I belive) all done 17:32:45 teor: agree (re meeting) 17:33:04 nickm: superseded, and the backoff has been superseded again by exponential backoff 17:33:30 does that have a proposal number? :/ 17:33:33 Do we need bits of the current state in the specs? 17:33:46 teor: I don't think I understand. 17:33:50 what do you mean? 17:34:36 So we implemented things instead o that proposal, do we need to document them in the spec documents? 17:34:46 huh. I think maybe we should. 17:34:50 nickm: prop#276 sounds ok at a glance. I am wondering a little bit about low capacity relays, but I also kinda think we should just raise the cutoff for them. they are a bottleneck compared to Tor's average throughput now, I think 17:34:55 especially if the specs document the old behavior 17:35:08 mikeperry: ack; thanks 17:35:49 nickm: I've updated some of them, I think 17:36:04 ok 17:36:29 tor's median relay is now 1.3 MB/s 17:37:02 cutoff++ 17:37:09 imho 17:37:23 Yes, there's a paragraph in dir-spec that starts "Each client also maintains a list of default fallback directory mirrors" 17:37:42 any other discussion topics for the group this time? 17:38:20 I brought up the idea of the team doing a monthly report jointly. Is that something we want to try on a Feb report, on a quick basis? 17:39:02 which team does the bandwidth authority rewrite belong to? 17:39:40 either metrics or network; not sure 17:40:38 I worry it has slipped between the cracks 17:41:05 teor: afaik about that, it's volunteers doing that work (dawuud and donncha) 17:41:13 Sebastian wants it soon so he can move on from an outdated distro 17:42:10 hm. Maybe this month we should try to do regular reports, and we should aim for a joint report in end-of-march? 17:42:36 isabela confirmed to me that having reports helps her do reports to funders 17:42:55 one more question: Are we satisfied with the sessions currently planned for the team day at the amsterdam meeting? 17:42:59 isis: re cutoff, I think using torperf or the bw auths average stream capacity to toss out relays with total capacity less than that seems reasonable. right now Torperf says that number is about 500KB/sec 17:43:07 I must admit I haven't looked at them enough. 17:43:12 nickm: find for the report on my side 17:43:34 nickm: so me and asn have planned one on 23rd for prop224 dev. work (really dev tech work we need to discuss) 17:43:45 nickm: anyone is welcome to attend 17:44:01 we might want one for our bi-yearly "retrostpective"? 17:44:15 so we do personal reports this month? haven't done them in a while as well. i'm fine to start again. 17:44:30 I'm okay with personal or team, but we should really do 'em, I hear 17:44:47 (fyi, I stopped listing ticket number in those reports, it became utterly painful to track them all....) 17:44:52 dgoulet: retrospective is good. I'd also like to get a 'long-term planning and goals' one 17:45:04 aha 17:45:07 nickm: ok just with net team or with a more global session? 17:45:14 nickm: (about the long term) 17:45:14 i think net team 17:45:49 the question being, with the recognition that our goals will depend on our resources, what do we actually want our objectives to be? 17:45:49 nickm: so on the 23rd seems a good time but then I think me and asn have two already on that day eheh 17:46:32 dgoulet: we could in theory move the UX+HS session later down this week, as flexlibris suggested. 17:46:43 *that week 17:47:02 there is either early morning or after 15h30 on 23rd 17:47:45 I am okay with any of those ideas; could I ask somebody to schedule these sessions? 17:47:52 nickm: can we fit like a retro and long term in the same meeting 17:47:57 and we schedule dunno like 15h30 to 17h30 ? 17:47:59 if the new core developer joins in amsterdam, should we have a session for sponsor4 too, nickm? 17:48:05 dgoulet: that sounds like it would work 17:48:12 ahf: I think we could have a breakout for that, yeah 17:48:16 ok let's try that I say 17:48:17 ack 17:48:18 not sure when 17:48:20 asn: yolo, 3rd meeting :P 17:48:29 what could go wrong 17:48:54 We might also look at evenings and see if we want to have an informal for-fun network-team dinner some time. We did one of those in valencia once and it went pretty groovily 17:49:13 maybe jon could arrange a reservation, if we asked him nicely, and we actually want to do it 17:49:23 nickm: not a bad idea 17:49:25 sounds nice 17:49:27 sounds good to me :) 17:49:48 FN_EMPTY 17:49:58 okay, I'll send him an email 17:50:06 anything else for today, or shall we adjourn? 17:50:18 ehm do we know when catalyst starts officially? 17:50:41 I believe, immediately before amsterdam. I believe he intends to be there. :) 17:50:47 excellent :) 17:51:00 ok 16h to 18h is booked on the calender for net team 17:52:20 who knows maybe an hour will be enough 17:53:30 we can hope 17:53:47 okay, meetbot, time for you to go back in your box 17:53:49 #endmeeting