16:59:31 #startmeeting Network team meeting, 27 February 2023e 16:59:31 Meeting started Mon Feb 27 16:59:31 2023 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:59:31 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:59:32 hiya 16:59:33 o/ 16:59:34 hello 16:59:37 last meeting of february 16:59:53 our pad is at https://pad.riseup.net/p/tor-netteam-2023.1-keep 17:00:19 * Diziet finds another copy of last year's url 17:00:32 how are y'all doing with your boards: https://gitlab.torproject.org/groups/tpo/core/-/boards ? 17:00:39 getting back into it 17:01:27 Mostly I need to pick up some more tickets. Should have a chat with nickm afterwards about what's happening next. 17:01:31 i don't see anything that is entirely off 17:01:34 sole focus here on Conflux 17:01:37 Diziet: sounds good - we also have some arti sync now 17:01:42 o/ 17:01:48 i think basically everybody are in hyper focused periods right now on some stuff 17:01:52 dgoulet: very nice 17:01:53 i've just been working on DoS and proof of work stuff 17:01:57 \o/ 17:01:59 very nice 17:02:27 we don't have anything on releases, right, dgoulet ? 17:02:53 should https://gitlab.torproject.org/tpo/core/tor/-/issues/40748 be tagged for 0.4.8 ? 17:03:18 ahf: correct 17:03:32 ahf: sure 17:03:35 oki, you tag it? 17:03:57 ahf: on it 17:04:10 excellent - i don't see anything else incoming from other teams 17:04:23 nickm has an announcement: [nickm 2023-02-27] Nick will be vactioning with family in Montreal from Aug 7 to Aug 11 of this year; please let me know ASAP if there's a conflict in there? 17:04:44 i don't see any issues with that and it is very early out :-p just put it in nc please if that hasn't been done already 17:04:45 nickm: in Montreal! niiice :) 17:05:24 okay, and we have another item: 17:05:26 [2023-02-27 ahf] google summer of code 17:05:30 dgoulet: lemme know if you want to hang out :) 17:05:47 or if there's anything you think we should do 17:05:49 so as some of you have seen it's the time of the year where hopeful gsoc applicants show up for projects in #tor, #tor-dev, #tor-project, etc. 17:06:17 Indeed so! 17:06:23 i have absolutely zero idea what state gsoc is in regarding tor right now, but for now just be kind and helpful to the folks joining, but of course don't spend too much energy on it if it all seems a bit hopeless 17:06:24 Personal msg even 17:06:34 Just a side question. Are these introductions necessary or more of a nice gesture? I am not quite familiar with the GSoC process. 17:06:49 once i have a bit more of an idea of the steps, i'll let you all know 17:06:56 I'm not very good with the inchoate kinds of queries that seem to be arriving but I will try. "Where shoud I look" etc. 17:06:58 But yeah, the vast amount of it is really nice :-) 17:07:14 It's nice to see people are keen, though. 17:07:16 one part that you should be having in mind though, is if you find people who would be a really good fit for this project, please talk with them about it somehow and keep a bit track of good candidates 17:07:30 emilengler: i am sorry, which introductions? the ones on irc? 17:07:36 Should I redirect people from privmsg to #tor-dev ? 17:07:37 ahf: exactly 17:07:49 Diziet: yes, i think so - better to have it in groups there 17:08:03 emilengler: i think it just always happens when we do gsoc or the other projects like that 17:08:06 we have the same with outreachy 17:08:24 i think on our wiki (which is linked from google's page) we mention the irc rooms as a place to go and ask questions 17:09:29 okay 17:09:36 i think that was it for the non-s61 part 17:09:43 mikeperry: are you here? 17:09:46 yep 17:09:55 you wanna takeover? then the rest can go do something else 17:09:59 thanks all o/ 17:10:06 so yeah as david said we're focusing on conflux 17:10:27 got it working on d2d34 the other week; I am writing unit tests.. fixing odds and ends, etc 17:11:04 sweet 17:11:09 we may be another week from sims, I think 17:12:00 jnewsome: I may ask you for a cloud runner for next week, depending on how fast that box moves 17:12:22 mikeperry: hmm I'm OOO next week 17:12:40 i could try setting it up at the end of this week and have it run through next week 17:13:09 jnewsome: oh hrmm ok maybe that could be a plan. I need to check that moving ticket but yeah, might be good to be safe to have a loud runner going that whole time 17:13:09 bit of a waste of quota, but i don't think we're hurting for quota 17:14:14 yeah, it also depends on how early we are ready to sim. but it looks like we might be ready to use it next week tho 17:14:17 ok, i'll try making the reservation now 17:14:39 just 1 runner you think? or? 17:14:46 just 1 is fine 17:15:37 you're out for just 1 week? 17:15:42 right 17:15:47 after that, we might want more. ok 17:16:55 juga: I saw you got onbrisca running, but did not have time to process how that was going (other meetings) 17:17:12 mikeperry: yeah, it's running 17:17:26 and rdsys sending bridges and receiving ratios 17:17:49 nice. is it using the ratio cutoff yet, or just konitoring for now? 17:18:20 using ratio, threshold is 0.75 17:18:46 rdsys only uses onbrisca information if it reports about 50% of bridges being functional 17:18:47 do we know if that is cutting out a significant number of bridges? do you have monitoring for that? 17:18:50 (over the threshold) 17:19:10 on Friday it was at 46% over that ratio 17:19:27 that is the part I didn't understand. so it is like bootstrapping? or it is marking too many as slow? 17:19:45 i think bootstrapping 17:19:59 there're bridges not measured yet, others failed 17:20:47 in any case, i think when bridgestrap says it's functional, it's being handled even if onbrisca says it's not, at least while it has less than the 50% functional according to onbrisca 17:20:54 ah ok. is that a bridgestrap behavior thing that it doesn't report on bridges it doesn't test yet, so it ends up not being used? 17:21:21 hmm, i don't know about that, i can have a look 17:22:42 ok yeah it would be good to understand where this decision not to use the data is being handled. these kinds of safety things end up killing UX, if they work where everyone suddnely starts gettting known broken/slow bridges just because the system is still bootstrapping 17:23:08 that is somewhat outside our scope, but it will be useful to know when monitoring behavior 17:23:26 ok, i'll look at that 17:24:38 cool. also the interaction between that ratio and the scan progress will be useful to watch 17:24:57 in any case, afaiu, if onbrisca didn't arrive to the 50% of bridges yet, it'll just continue using bridgestrap as before 17:25:06 ok 17:25:12 a better kind of safety might be to use a much lower ratio while the system is still bootstrapping, rather than ignoring all liveness and measurement results 17:25:31 i see 17:25:33 ah, I see. so it is not ignoring everything, just the ratios 17:25:38 ok that is a bit better 17:25:39 yes 17:26:08 (sorry i didn't get you at first0 17:26:12 ) 17:26:31 as for the deadline, the main factor is the audit.. technically we will have more time for S61 to make sure the audit of changes gets done and bugs can be fixed 17:26:41 but those are details are still being worked out 17:26:55 ah, ok 17:28:05 GeKo: at some point we should revisit https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/49 to finish those param testing, but that may be a factor of ddos activity and conflux work 17:29:46 ack 17:30:56 I think that is it then 17:31:33 very nice 17:31:41 thanks all o/ 17:31:48 #endmeeting