16:58:19 #startmeeting network team meeting november 30 2020 16:58:19 Meeting started Mon Nov 30 16:58:19 2020 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:58:19 Useful Commands: #action #agreed #help #info #idea #link #topic. 16:58:27 hello hello to the last network team meeting of november 16:58:38 https://pad.riseup.net/p/tor-netteam-2020.1-keep 16:58:40 is our pad 16:58:41 hi everybody! 16:58:46 o/ 16:58:48 o/ 16:59:00 o/ 16:59:02 o/ 16:59:47 how are oflks doing with their boards? 17:00:06 o/ 17:00:09 o/ 17:00:09 so far so good 17:01:14 buenos 17:01:37 are we ok with review assignments? 17:01:51 I don't see any new ones for me... 17:02:07 look like it hasn't happen yet 17:02:11 has not been assigned yet afaict 17:02:15 ok 17:02:32 looks like we have four unassigned 17:03:38 i see no new 0.4.5 tickets? 17:04:20 yeah though maybe we should hmmmm 17:04:33 ? 17:05:06 maybe we should add a weekly item to see if anything new in https://gitlab.torproject.org/groups/tpo/core/-/issues needs to be assigned or put in a milestone 17:05:12 so we stay up-to-date with triage 17:05:34 i have a question on triage after this 17:06:04 i think me or someone should try to ensure that at least labels and milestones are /somewhat/ okay for new things coming in for tpo/core 17:06:22 i've been trying a bit for that in the last week, but i don't think it was spot on, but maybe it will just improve if i continue 17:06:33 i have noticed you also do that quite a bit, nickm, which is very good 17:06:48 there are a few IPv6 ones; dgoulet, are you able to have a look and put them in 0.4.5 if they're regressions? 17:06:53 ugh sorry just exited another meeting 17:07:00 there's an onion services one there too 17:07:04 give me a sec to recalibrate and write update 17:07:06 yes, s7r opened a few v6 tickets and some on onion services 17:07:14 nickm: yes, they are all flagged in my email, need to put them in my queue for real 17:07:21 great 17:07:25 asn: no worries! update can wait until after if you want to, no rush 17:07:44 okie 17:07:52 okay, I think we're fine then 17:08:25 ok good good 17:09:30 i see no announcements and no discussion topics today. this means we transition to the s61 part of our work now. remember that next week we have the "long" start of the month network team, but it also means there is an s61 specific meeting via bbb on monday 17:09:43 mikeperry: do you wanna head the s61 one stuff here? 17:09:49 yeah ok 17:10:06 long start of the month network team meeting* 17:10:08 I put updates for s61 in the pad. things seem to be moving nicely 17:10:34 the monthly S61 planning meeting is Dec 7 at 15utc. pad link is in my summary for s61 17:10:59 perfect 17:11:05 asn, karsten, gaba, and I should discuss guard-based onionperf experiments, thoroiughness, and who does what 17:11:47 asn is concerned about a lot of experiments being done for CBT, but these can help us with future guard-based experiments.. some things might be doable by karsten and automated more tho 17:12:00 yeah a bit of automation would be helpful 17:12:04 but im done with 1/3 of the experiments as of today 17:12:29 I have a MR for CBT fixes and a spec patch. asn I guess you foiund a guard issue? 17:12:30 i havent managed to automate tgen yet (so that it stops after it causes 1000 timeouts) 17:12:50 i tried to read that MR. that was a corner of tor i had not looked at before 17:12:53 so that i can just make a bash script that does all the experiments 17:12:59 mikeperry: i started reviewing the MR today 17:13:16 mikeperry: i found a guard issue yes. i will file it later today or tomorrow. 17:13:30 nice. you can assign me a similar sized review next week in exchange for the review, if you want :) 17:13:50 haha thanks for the offer 17:13:56 let's see how hard this is gonna be 17:14:10 i have some questions already but i need more time to put them in gitlab 17:14:26 ok great. that covers objective 1 update. juga wrote a good synopsis for objective 2 to find candidates for unmeasured relays: https://gitlab.torproject.org/tpo/network-health/sbws/-/issues/29710#note_2717173 17:14:49 juga: have we been able to look at the connectivity relays vs the unmeasured set yet? 17:15:05 (I can ask later in the sbws channel if you're not here, no worries) 17:15:15 mikeperry: GeKo has been looking at unmeasured relays 17:15:25 none of us has been looking at connectivity yet 17:15:32 was ahf doing that? 17:15:50 i actually have looked at that, too 17:15:52 yeah ahf posted a script and results from a paticular day. I am not sure if we have sbws data from that day 17:15:55 this week planning to look more on the unmeasured relays 17:16:00 last week 17:16:09 mikeperry: i can search for that later 17:16:30 it is on the sbws#29701 17:16:41 and found that there is no real difference between torflow and sbws 17:16:44 i mean, if there's other data for that day 17:16:57 GeKo: in the unmeasured set? 17:17:34 ye, geko looked at that last weke i think 17:17:38 yes 17:17:40 ugh, out of sync scrollback 17:17:54 i still need to update the ticket 17:18:19 ok cool. interesting. I thought historically this mismatch was a problem 17:18:30 it could be 17:18:44 but it is not explaining the bigs gaps alone at least 17:18:51 i'd have to look at my notes 17:18:54 ok 17:19:30 well for objective 3, dgoulet wrote a conflux draft. I still need to look it over and think about side channel issues and add them. but v exciting! 17:19:39 neat 17:19:48 \o/ 17:20:53 oh yeah, and rob is re-running the flashflood shadow experiment again. I told him that we don't necessarily need to dig if shadow can't see it; we can try to reproduce on live if shadow is tricky 17:21:31 I wonder if it is also a DNS issue (the 95th percentile flashflood problem). could be related to our DNS scanning work in objective 4. but that is a guess 17:21:57 and also for objective 4, I need to go over dgoulet's overload descriptor proposal. hope to do that this week 17:22:25 and next week is the planning meting. again, dec 7, 15 utc. hope my internet is better this time :) 17:22:25 hm, is the DNS issue something new? or is that related to the work that has happened with detecting OpenDNS resolvers too? 17:22:42 that is what I am wondering. aurthor fo9und many DNS timeouts 17:23:09 i think that should be getting better 17:23:10 and very good with flashflood - and maybe the source code will be home for christmas 17:23:18 it could be that when given more load due to flashflood, those relays were timing out. the 95th percentile was at a weird 10s perf cliff. which sounds like some kind of timeout happening due to load 17:23:21 as we badexit relays or get them to fix their setup 17:23:29 but might take a bit of time... 17:24:15 idk if Shadow can simulate DNS failures. if it can't, that could be our mismatch.. we should fix that, if so. anyway, more info needed 17:24:45 what tooling exists today to deal with the DNS issues? 17:24:52 and we have tickets for this? :o 17:24:59 mikeperry: I don't think it can today. name resolution happens instantaneously 17:25:16 it doesn't model the actual dns network protocol 17:26:03 maybe we can kludge up whatever it uses as a resolver to have a node-dependent probability of failure? 17:26:09 interesting. it could also be some exit-side TCP timeout too, if that is also instant 17:26:37 nickm: yeah, probably wouldn't be too difficult 17:26:54 does shadow actually do the DNS resolving in a simulation or are they faking the results there too? 17:27:34 ahf: it doesn't talk to the real network at all, no 17:28:03 ok 17:28:08 the failure might be due to tor-side overload and dropping requests there when load is high. making the resolver merely unreliable might not see it. this was a very clear, persistent, 10s cliff... I think it is some kind of timeout issue thet shadow might not see. or maybe it can. rob is still re-running last I heard 17:28:09 dns resolution is handled inside shadow, using the name<->ip mappings from the simulation config 17:28:15 oki 17:29:39 I think that is it unless others want to bring up more 17:29:59 cool 17:30:02 * ahf is good 17:30:48 sounds like there is nothing 17:30:51 let's end the meeting then 17:30:53 thanks all o/ 17:30:56 o/ 17:30:58 #endmeeting