15:58:43 <GeKo> #startmeeting network-health 06/26/2023
15:58:43 <MeetBot> Meeting started Mon Jun 26 15:58:43 2023 UTC.  The chair is GeKo. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:58:43 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:58:47 <GeKo> hello!
15:58:55 <GeKo> we have our pad at https://pad.riseup.net/p/tor-nethealthteam-2023-keep
15:59:00 <mattrighetti[m]> o/
15:59:11 <GeKo> so, have a look at it and/or add your stuff you worked on
15:59:52 <juga> o/
16:00:08 <ggus> o/
16:00:32 <RishadBaniya[m]> hey there everyone, i hope everyone is doing well
16:00:44 <RishadBaniya[m]> i have few questions to ask today
16:00:59 <GeKo> RishadBaniya[m]: go ahead!
16:01:40 <hiro> o/
16:02:36 <RishadBaniya[m]> what's the most optimal amount of circuits that i should involve a SINGLE RELAY within in a timeframe of 1 minute, i mean what do you think should be the judging criteria
16:02:47 <RishadBaniya[m]> of determining the no of circuits the RELAY is to be involved in
16:02:56 <RishadBaniya[m]> whether it's the first hop or the second hop of the circuit
16:03:33 <GeKo> i am not sure i get the question
16:03:36 <juga> RishadBaniya[m]: probably the limit is in the maximum file descriptors the relays can open by average
16:04:28 <juga> instead of trying to create a circuit with a relay and all the rest, you could also just build 1 circuit per relay and then go back to that relay
16:04:49 <juga> or you mean just to consider whether the circuit failed or not?
16:04:51 <RishadBaniya[m]> i mean the relays with the high consensus weight are the ones that are probably getting selected for the "real life" use cases, so will it be good to involve the relay in high number of circuits within a X timeframe
16:05:27 <juga> RishadBaniya[m]: i don't know about that, let's ask at #tor-dev after this meeting
16:06:05 <GeKo> yeah
16:06:52 <GeKo> i think juga's "build 1 circuit per relay and then go back to that relay" is a decent plan to start with as well
16:06:55 <RishadBaniya[m]> i was thinking of this algorithm, at any instant of time a relay can be involved in 2 circuits(one where it's the first hop and second one where it's the second hop) and after every completion of those circuit attempts we wait for let's say 30 seconds to create the next circuit until the relay makes circuit with all the remaining relays
16:07:24 <RishadBaniya[m]> but this delay of time, just to make sure we are not creating circuits too fast and adding load into the network seems
16:07:31 <RishadBaniya[m]> so dynamic in a sense that how to vary it
16:08:04 <juga> RishadBaniya[m]: yeah, you could avoid the delay with the just 1 circuit per relay at a time
16:08:40 <juga> but i'm not sure what's the best algorithm here, we can optimize it later on
16:08:46 <GeKo> +1
16:09:46 <GeKo> RishadBaniya[m]: do you have anything else we should discuss here?
16:09:57 <RishadBaniya[m]> sure, as of right now i'm planning on running all 6000 relays on their on async task doing things independently, kind of tracking who've already created circuit with and who they should build with....i guess i will overthink a bit tomorrow and the day after tomorrow to come with a better approach
16:10:31 <GeKo> sounds good
16:10:55 <RishadBaniya[m]> so should i only stick to one circuit at a time?
16:11:09 <juga> at the moment, i think that's fine and easier
16:11:14 <GeKo> yeah
16:11:31 <RishadBaniya[m]> and about the delay on creating the next circuit
16:11:39 <RishadBaniya[m]> should i fix it for now
16:11:42 <RishadBaniya[m]> for X seconds
16:12:09 <juga> if there's only 1 circuit per relay at a time, no need for delay
16:12:25 <juga> you could also have a variable for that, that we can change later
16:12:54 <RishadBaniya[m]> sure
16:13:11 <mattrighetti[m]> Update on network status APIs: All good so far, I got both /summary and /details working as of now and I’m working on the /bandwidth endpoint right now. For the others I’m waiting to get pg access as I need to take a look at real data from the db to get a better understanding of how the object is created from those queries. Query params are half implemented for summary but I’ll work on those after setting every endpoint up
16:13:11 <mattrighetti[m]> with  the basic response. I’ll try to make a !2 by the end of the week with some of the endpoints working without query params
16:13:32 <GeKo> \o/
16:13:34 <GeKo> very nice
16:13:41 <hiro> xD yes very nice
16:14:41 <GeKo> let's see what i have on my list of things to mention here...
16:14:55 <GeKo> ggus: hiro: we should find a time to prep our all hands session about s112 a bit
16:15:19 <GeKo> we moved it to 07/05, which is next week...
16:15:31 <GeKo> i know somewhat surprisingly :)
16:15:38 <ggus> :O
16:16:51 <ggus> GeKo: do you think we should focus on s112 roadmap?
16:16:59 <GeKo> i mean i could ask pavel to move it again, but maybe that's not the smartest idea...
16:17:04 <ggus> because bad relays is more than s112
16:17:08 <GeKo> you mean for the all hands?
16:17:11 <ggus> yes
16:17:46 <GeKo> i think we should focus on the metrics-db
16:17:55 <hiro> I was thinking to do a little show and tell of the data in the database and how we can query from grafana
16:17:56 <GeKo> and the new relay-ops processes
16:18:01 <hiro> and have a few issues fixed on tagtor
16:18:05 <GeKo> hiro: yeah
16:18:20 <GeKo> and we could mention o3 briefly
16:18:31 <GeKo> so, focusing on o1 and o2 is likely the right thing
16:18:44 * juga is very interested in this demo
16:19:07 <GeKo> ggus: i think the roadmap for s112 could be part of it
16:19:25 <GeKo> but i would like to avoid just having the all hands be a roadmapping session :)
16:19:43 <GeKo> i think we should embed it into the larger context of bad-relay and network health work
16:20:07 <GeKo> showing how O1 and O2 make progess here
16:20:12 <GeKo> and what that entails
16:20:13 <ggus> okay, happy to talk about o2 progress
16:20:22 <GeKo> (new tools and new processes etc.)
16:21:03 <GeKo> ggus: hiro: when would be a good time to nail the agenda down a bit?
16:21:17 <GeKo> what about thu 1400utc?
16:21:43 <ggus> i can do thu 13utc
16:22:22 <GeKo> hiro: could we move our sync to 1400utc and we'd do the all hands prep on 1300utc?
16:22:33 <hiro> yep on Thursday right?
16:22:48 <GeKo> yeah 06/29
16:22:57 <hiro> yep sounds good
16:23:09 <GeKo> okay, 1300utc all hands prep it is, thanks
16:23:17 <GeKo> i don't have anything else
16:23:23 <GeKo> ggus: anything from your side?
16:23:36 * juga is good
16:24:12 <ggus> GeKo: yes
16:24:36 <ggus> i'll send the relay op meetup notes this week to the mailing list
16:24:52 <GeKo> nice
16:24:59 <ggus> but i think it's a good idea to send an email about the relay operator metaproposal
16:25:12 <ggus> wdyt?
16:25:49 <GeKo> yes, please
16:26:17 <ggus> ok, i'll put together an announcement to the mailing lists
16:26:24 <GeKo> i think it would be good to give the relay ops community on tor-relays@ a heads up and the option to provide feedback
16:26:37 <GeKo> not just the folks who participated in the meetup
16:26:47 <ggus> https://gitlab.torproject.org/tpo/community/policies/-/issues/2
16:26:52 <GeKo> i think at least nusenu was interested in that metaproposal
16:27:12 <GeKo> and i don't know whether they were at the meetup nor whether they were following the ticket
16:27:33 <ggus> hi, if you're reading this irc logs, please read this super important proposal ^^^
16:27:40 <GeKo> heh
16:27:52 <GeKo> ggus: did you get any feedback from non-tpo folks so far?
16:28:16 <ggus> no, not yet. but it was announced publicly on saturday. and it's a long document
16:28:30 <GeKo> true
16:28:56 <GeKo> okay.
16:29:02 <GeKo> anything else for today?
16:29:08 <ggus> and the world was upside down last weekend. so i completely understand that reading the metaproposal wasn't high prio
16:29:26 <GeKo> true thing, hilarious
16:29:43 <ggus> GeKo: i'm planning to call for votes this week: https://gitlab.torproject.org/tpo/community/policies/-/issues/7
16:29:54 <GeKo> +1
16:29:56 <ggus> i'll get in touch with sebastian
16:30:28 <GeKo> feel free to cc me to any email convo if you feel that's a good thing to do
16:31:23 <ggus> ok!
16:31:28 <GeKo> alright, i looked over the other entries on the pad and the planned s112 work for this week looks good to me
16:32:00 <GeKo> ggus: you good?
16:32:11 <GeKo> hiro: ^
16:32:19 * ggus is good
16:32:23 <hiro> yep
16:32:25 * hiro is groot
16:34:31 <GeKo> great
16:34:39 <GeKo> thanks everyone then and have a nice week o/
16:34:42 <GeKo> #endmeeting