17:59:14 #startmeeting weekly network team meeting, 8 jan 2018 17:59:14 Meeting started Mon Jan 8 17:59:14 2018 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:59:14 Useful Commands: #action #agreed #help #info #idea #link #topic. 17:59:19 hi everybody! 17:59:21 hi 17:59:24 hoop hoop hooray 17:59:25 https://pad.riseup.net/p/whmabDRQ1yZZ is the pad 17:59:33 hello hello 17:59:34 beep boop 17:59:40 hello o/ 17:59:50 and happy new year! 17:59:55 wheeeee 18:00:44 so, let's everybody who hasn't written an update please do so now 18:00:52 and remember to boldface stuff you would like to talk about 18:01:07 if you've written your update, please read everyone else's... 18:01:20 and have a look at December/January on https://docs.google.com/spreadsheets/d/1Ufrun1khEo5Cwd6OwngERn829wU3W3eskdrriaYfUBQ/edit?usp=sharing 18:01:34 maybe november too -- not everything there is marked. 18:01:43 I'm thinking we should spend some time updating that roadmap soon 18:02:40 oi 18:02:40 ! 18:02:48 hihi 18:02:58 * isabela adds stuff to the pad 18:03:15 I see stuff in November and December that we didn't mark done. I don't know whether it's finished, blocked, to-be-deferred, etc 18:05:09 isabela: what should we do with the "UX +onion" roadmap entry? 18:05:19 isabela: we moved forward a lot, but maybe not done yet. should we move to feb or so? 18:05:31 or consider it done for today? 18:05:37 s/today/now 18:05:38 asn: i think one ticket is ready to get tb implementation discussion started, the other needs to get your proposal moving 18:06:05 asn: so, i would just keep the one that has the proposal open still 18:06:42 mikeperry: yoooo 18:06:52 mikeperry: happy new one! 18:07:49 asn: heyo! 18:08:16 isis, mikeperry, asn, ahf, nickm, catalyst, dgoulet have things in November that aren't marked as done. 18:08:54 nickm, isabela, armadev, dgoulet, catalyst, asn, ahf, mikeperry , and "team" have stuff that aren't marked done in December. 18:08:58 isabela: does the s4 comment mean i can charge some hours on an s4 related issue to s4 as sponsor in harvest? 18:09:07 (I hope lots of these things actually are done) 18:10:05 Does anybody else feel they can review komlo's #23881 some time early this week? if not I can assign myself as reviewer 18:10:47 review would be great, especially how we want to handle log level macros in C 18:11:03 ahf: s4 is otf so i think no one from network team has been adding hours there since 18:11:15 nickm: that does remind me of a higher-level concern i have about logging that we can discuss later in the meeting or on the ticket 18:11:16 komlo: my answer to your question about refactoring on C side is probably to do it separately _unless_ there's a reason it should be a part of the rust thing 18:11:23 isabela: ack, i will make it fast and put it in as overhead somehow 18:11:26 nickm: i will review it the roadmap 18:11:45 isabela: thanks 18:11:50 ahf: maybe i am not understanding 18:12:00 what you will make fast? 18:12:20 catalyst: maybe make a comment on the ticket? 18:13:17 isabela: just get the work done quickly :-) i was just wondering as the work is a bit related to the s4 stuff we did 18:13:22 nickm: refactoring separately would be great 18:13:36 komlo: sounds good 18:13:46 catalyst: or as a new ticket as appropriate 18:13:49 isabela: should i move "UX improvements for onion" to a later month then? like feb? 18:13:55 also we can discuss too, time permitting 18:14:32 asn: wrt the name system proposal -- I think there are actual users among the namecoin people. when you talk to the folks who might implement, maybe put them in touch with each other 18:14:58 nickm: what do you mean "actual users"? 18:15:06 nickm: i've talked to jeremy a bit about namecoin+tor 18:15:17 asn: i think (if you have bandwidth) you should keep that ticket where we are still working on that proposal 18:15:22 although he never expressed interest in implemting prop279. he expressed interest in using it if it exists. 18:15:28 perhaps i should get them in touch anyhow 18:15:33 asn: the other one, i think it can be moved to the tb team roadmap :) is on their plate now 18:15:48 asn: I think that the namecoin people (Jeremy?) have (semi?)working code on their side, using a controller-based kludge to implement Tor's part of it 18:15:56 asn: ah, nm 18:16:11 I think jeremy was also interested in maybe revising prop279 if needed 18:16:11 asn: oh, so, the network team deliverable was already reported as done a while back :) 18:16:14 ops 18:16:18 ahf: ^^ this was for you 18:16:19 yeep 18:16:29 cool! that was also what i thought, thanks :-) 18:16:31 so i am not reporting on that just the open ones from Tb team 18:16:51 sorry i got you confused! hehe nothing here for network team, just that iw ill be busy with it 18:17:08 i do have a dependency for the moat task on isis tho 18:17:13 but that is in another update 18:17:19 yep, no worries :-) 18:17:49 isabela: eeeeh, i'm still not sure what i should do with the november roadmap item based on the above. i'll leave it as is for now... 18:18:07 not sure what you mean by "you should keep that ticket" 18:18:30 catalyst: hope you get rid of the virus! 18:18:51 ahf: thanks! 18:19:31 ahf: lets schedule a discussion about tracing after the meeting? 18:19:39 nickm: ack 18:19:46 asn: let me udpate it 18:19:49 isabela: thx :) 18:19:55 Does anybody know isis's status? I haven't seen them on IRC this year. 18:20:18 isabela: the task "Build plan for improvements to Tor for integration on iOS, Android" isn't something we have discussed much wrt to ios - i met with benjamin at congress and talked there, but i'm not going to mark it DONE on the roadmap yet 18:20:35 dgoulet: can we do it tomorrow? i'm going to run to the shop right after the meeting and cook some soup for a sick gf 18:20:48 ahf: yup! np 18:21:22 Let's do the easier discussion questions while people continue to update Nov through Jan on the roadmap 18:21:27 two quickies from me: 18:21:36 Any objection to calling 0.3.2.9 a stable release? 18:22:03 Any objection to having stable releases for the other series come out later this week or early next? I'm thinking of the #24666 backport in particular. 18:22:17 none 18:22:38 none 18:22:49 ok. mikeperry , I think you've got next questions? 18:23:02 then dgoulet 18:23:08 yeah 18:23:21 my questions are mostly for dgoulet I think. 18:23:46 dgoulet: right before break, I saw you, sebastian, and armadev experimenting with cbt options. Did you find anything I should look at? 18:24:07 mikeperry: yeah to you noticed that two param have been changed in the consensus? 18:24:17 mikeperry: I've CCed you on some tickets about all this today 18:24:37 ahf: i thought that was the result from all these conversations (like the work you doing that ooni opened the ticket for etc, I do think it can be marked at done, this was back in november when you met them at tor meeting and briar at otf etc) 18:24:58 ok. I remember it seeming like results weren't controlled or conclusive, but that was back on like dec 24th 18:25:35 isabela: ahh, yes, of course. i didn't think of the ooni part, yes. i'll mark it as closed, a lot of these things have already landed by nick 18:25:54 mikeperry: #24716 18:26:19 nickm: what's the plan for #21074? 18:26:35 I wrote a patch; nobody has reviewed or tested it. 18:26:40 just breaking is a pretty bad experience 18:26:59 Merging patches that are not reviewed or testd can also produce a bad experience :) 18:27:07 mikeperry: might want to look at #24768 and #24769 as well (and the one I CCed you couple hours ago) 18:27:24 nickm: sure. that's why i asked about your plans :) 18:28:19 "merge it when it is reviewed & tested" :) 18:29:25 catalyst: hello. i was not aware of #24661. i'll try to take a look this week, and try to remember why we added a check for live ocnsensus on the guard algo 18:29:49 dgoulet: the fact that we changed both cbtmintimeout and cbttestfreq make mesad for science. do we really think we need cbtmintimeout to be changed? 18:29:52 catalyst: feel free to ping me next time you open or investigate guard-related issues so that I can help you :) 18:30:27 asn: thanks! it would be good if we had a comprehensive security analysis of consequences of consensus liveness (or non-liveness) 18:31:08 mikeperry: I think the point was about calming down the influx of circuit creation and also to try to confirm that it might indeed be just a thundering herd of clients instead of a full on DDoS attack, not sure the goal was for those value to stick 18:31:11 catalyst: true. sounds complicated tho, these has_live_consensus() has_reasonably_live_consensus() functions are used everywhere in the code. 18:31:27 mikeperry: but with the new tickets opened by teor, maybe there is a discussion to have, Roger also has an opinion I think 18:33:34 dgoulet: do you need anything from me on the network load situation this week? I like the stuff I've been seeing on trac, but I don't have much of a current plan to make progress on it this week. 18:34:28 ok if we jump in that topic, I was mostly wondering if anything had changed since I dissapeared, I think I catched up with most of it on Trac for now 18:35:16 there are a lot of things we can start working on to try to improve tor to work better with this load but they might not be suitable for "backport" as they will probably be in depth changes in some ways 18:35:18 from talkin to roger on ccc, all i know is that we switched those consensus params 18:35:20 asn: row 72 is what i moved to jan regarding onion ux stuff 18:35:22 i dont think anything else was done 18:35:31 yeah I was still alive when we did that 18:35:32 but might be wrong 18:36:04 isabela: excellent 18:36:07 so mostly my questions is what can/should we do next... as this isn't roadmap/sponsored stuff :S 18:36:20 dgoulet: ye... 18:36:28 this might be something worthy of an irc mtng or sth 18:36:28 A relay operator complained on trac that we hadn't backported the memory fixes, confirming in the process that 0.3.2.8-rc was working better than the older series 18:36:32 since i doubt we can figure it out in this mtng 18:37:38 yeah my relay on 0.3.2.8-rc is working properly and not going too crazy but still goes to lots of RAM ... destroy queue is important fix than the KIST fixes as well, for <= 031, it is still unclear :S... 18:38:24 asn: would you be willing to try to schedule an IRC meeting with interested devs some time in the next day or 2 then? 18:39:14 anyway, not sure what we can do more in this meeting so we'll continue on Trac I think for now 18:39:21 o 18:39:21 ok 18:39:24 nickm: im flyin to rwc tomorrow so not the best person for this week :( 18:39:28 ah, ok 18:39:42 sorry about that 18:39:46 np 18:39:53 anybody else able to set that up? 18:40:04 or maybe we should all look more, and see where we're at 18:40:12 maybe a tor-dev thread? 18:40:27 a "state of things" thread 18:40:51 yeah agree on that ^ we should sync up and do one, teor seems to have looked at this quite a bit last week 18:40:51 or a "mitigations and taking stock" thread 18:40:55 yeah 18:41:12 I'm hoping it can be info-focused rather than "relay operators paste logs at random" 18:41:22 proposition: I'll start one on netteam list and once we are synced, we go on tor-dev@ ? 18:41:23 (that part is important too, but we need analysis) 18:41:29 dgoulet: yes please! 18:41:45 ack 18:41:58 asn: I pushed the missing bug23101 commit to bug23101-squashed. not sure how I missed that.. 18:42:08 mikeperry: thx 18:42:13 next general-discussion issues: 18:42:31 we are supposed to start coming up with gsoc ideas, I think. Let's try to do that, and let's try to emphasize rust if we can 18:42:32 will try to do some real-life testing while on rwc this week. but probs won't have too much time. 18:43:00 mikeperry: will try to be somewhat on irc every day tho. 18:43:59 (If you have a rust project in mind that you won't get to before summer, think about whether you'd maybe like to mentor it) 18:44:20 other topic -- anybody know about the status of our team/hack day(s) for rome? 18:44:21 what about that bandwidth scanner for bwauth's that we talk about "often"? 18:44:30 is that too big of a project? 18:45:06 doing it from scratch might be too big, but I think there's work in progress somewhere? it depends on the status though 18:45:08 asn: ok. I will also work on testing and readme's and such. 18:45:11 I suspect/hope some Mozilla people working on the proxy will be there, so maybe some time about that? 18:45:19 maybe there's some part of it too... 18:45:22 tjr: there == rome? 18:45:30 nickm: nickm Yes 18:45:33 cool 18:45:57 Also is what you're talking about I believe https://github.com/TheTorProject/bwscanner 18:46:07 also cool :) 18:46:07 Current status is "Let's run it and compare its output" 18:46:21 sounds like doing that is a first step to see how it goes 18:46:31 and then we can know more about what would be needed there for the summer 18:46:46 and whether there is a) enough work for a gsoc student b) too much c) too little 18:46:53 mikeperry: great. the guard issue is an important one to address and test. 18:47:18 I think we're running low on listed discussion topics. catalyst: did you want to talk about the logging thing here, or on #tor-dev afterwards? 18:47:24 and any other topics for this week's meeting? 18:47:37 please remember to have another look at the roadmap spreadsheet, and update if you haven't already done so 18:47:38 asn: ack 18:47:53 * ahf will request approval for traveling budget and go over the roadmap stuff after the meeting 18:48:07 nickm: briefly, if we go to a flat string for logging, are we closing any doors we ought not to? 18:48:42 mikeperry: excellent 18:49:00 catalyst: So, conceptually we log a tuple of (time, severity, domain, string.) In what sense did you mean "go to a flat string" ? 18:49:30 dgoulet: do you think we can safely remove cbtmintimeout from the consensus? I am hoping it should not matter and that hypothesis 2 is not happening (on #24716) 18:49:36 in that the "string" is a printf-like format string with variadic arguments, isn't it/ 18:49:39 ? 18:49:58 ah. yes. 18:50:19 dgoulet: if that does matter, then something deeper may be wrong with the cbt code 18:50:26 So do you mean, "should we preserve the idea that log messages might be a message-type plus some arguments" ? 18:50:49 and make them conceptually more (time, severity, domain, string, [arguments]) 18:50:52 ? 18:51:01 mikeperry: not 100% sure, tbh this is difficult to say :S ... the idea was I think to make client not retry CBT too often so increasing the timeout makes it that a tor client waits that amount of time before opening more circuits no? 18:51:12 if we do that we can start using systemd's journald features more nicely 18:51:21 nickm: yeah. arguably we're nowhere nearly disciplined enough with it currently so maybe we should construct a more structured logging facility later 18:52:03 dgoulet: no. that param just says "don't time out on a circuit before 5 seconds, regardless of the timeout value you learned." 18:52:20 yeah; our system right now is really built around the idea that "it formats into english sentences". If we wanted to do something structured, I think we'd have to actually specify what the interface is. 18:52:23 clients should not be learning cbt values that cause them to time out more than 20% of their circuits, no matter what 18:52:24 and what kind of stability to expect etc 18:52:45 so that param should have little to no effect, unless there are deeper problems 18:53:36 and I would like to have an idea if therre are deeper problems. because if there are, then fixing the other tickets is just a bandaid and will not help 18:54:18 nickm: this might be a good gsoc project, but it might also be too small? not sure about the time committment. https://trac.torproject.org/projects/tor/ticket/24249 18:54:32 oh, that's interesting. 18:54:32 yeah 18:54:37 that could be huge, or it could be tiny 18:54:43 it would need some engineering taste 18:55:01 maybe we can make different goals- ie, a mvp, and stretch goals 18:55:03 mikeperry: so as far as I can tell you, the work/analysis I did had nothing to do with CBT... Roger proposed to changed those just to learn if those were indeed crazy amount of clients just joining and non stop looping on CBT because the network is just crumbling on their loads 18:55:48 komlo: yeah. and also we could do a design sketch, to give some structure to the work 18:55:57 mikeperry: isn't that "don't time out on that circuit before 1500 seconds" will make client hold on those circuits longer and thus create less circuit in the process? 18:56:58 tor browser meeting in 3 minutes 18:57:30 anything more for this week? I'll be on #tor-dev for a bit afterwards, at least 18:57:31 mikeperry: we can talk on #tor-dev but having Roger nearby would be useful as it is spotty in my head why that one was bumped :S 18:57:54 dgoulet: it shouldn't make them create more than 20% less circuits, is what I am saying. it should be marginal. unless there is a feedback loop or other bug. 18:58:00 but yes, #tor-dev 18:58:25 thanks all! 18:58:27 nickm: can kill the bot :) 18:58:27 #endmeeting