16:58:19 <ahf> #startmeeting network team meeting november 30 2020
16:58:19 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
16:58:27 <ahf> hello hello to the last network team meeting of november
16:58:38 <ahf> https://pad.riseup.net/p/tor-netteam-2020.1-keep
16:58:40 <ahf> is our pad
16:58:41 <nickm> hi everybody!
16:58:46 <ahf> o/
16:58:48 <juga> o/
16:59:00 <dgoulet> o/
16:59:02 <mikeperry> o/
16:59:47 <ahf> how are oflks doing with their boards?
17:00:06 <GeKo> o/
17:00:09 <jnewsome> o/
17:00:09 <dgoulet> so far so good
17:01:14 <ahf> buenos
17:01:37 <ahf> are we ok with review assignments?
17:01:51 <nickm> I don't see any new ones for me...
17:02:07 <ahf> look like it hasn't happen yet
17:02:11 <dgoulet> has not been assigned yet afaict
17:02:15 <nickm> ok
17:02:32 <ahf> looks like we have four unassigned
17:03:38 <ahf> i see no new 0.4.5 tickets?
17:04:20 <nickm> yeah though maybe we should hmmmm
17:04:33 <ahf> ?
17:05:06 <nickm> 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 <nickm> so we stay up-to-date with triage
17:05:34 <ahf> i have a question on triage after this
17:06:04 <ahf> 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 <ahf> 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 <ahf> i have noticed you also do that quite a bit, nickm, which is very good
17:06:48 <nickm> 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 <asn> ugh sorry just exited another meeting
17:07:00 <nickm> there's an onion services one there too
17:07:04 <asn> give me a sec to recalibrate and write update
17:07:06 <ahf> yes, s7r opened a few v6 tickets and some on onion services
17:07:14 <dgoulet> nickm: yes, they are all flagged in my email, need to put them in my queue for real
17:07:21 <nickm> great
17:07:25 <ahf> asn: no worries! update can wait until after if you want to, no rush
17:07:44 <asn> okie
17:07:52 <nickm> okay, I think we're fine then
17:08:25 <ahf> ok good good
17:09:30 <ahf> 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 <ahf> mikeperry: do you wanna head the s61 one stuff here?
17:09:49 <mikeperry> yeah ok
17:10:06 <ahf> long start of the month network team meeting*
17:10:08 <mikeperry> I put updates for s61 in the pad. things seem to be moving nicely
17:10:34 <mikeperry> the monthly S61 planning meeting is Dec 7 at 15utc. pad link is in my summary for s61
17:10:59 <ahf> perfect
17:11:05 <mikeperry> asn, karsten, gaba, and I should discuss guard-based onionperf experiments, thoroiughness, and who does what
17:11:47 <mikeperry> 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 <asn> yeah a bit of automation would be helpful
17:12:04 <asn> but im done with 1/3 of the experiments as of today
17:12:29 <mikeperry> I have a MR for CBT fixes and a spec patch. asn I guess you foiund a guard issue?
17:12:30 <asn> i havent managed to automate tgen yet (so that it stops after it causes 1000 timeouts)
17:12:50 <ahf> i tried to read that MR. that was a corner of tor i had not looked at before
17:12:53 <asn> so that i can just make a bash script that does all the experiments
17:12:59 <asn> mikeperry: i started reviewing the MR today
17:13:16 <asn> mikeperry: i found a guard issue yes. i will file it later today or tomorrow.
17:13:30 <mikeperry> nice. you can assign me a similar sized review next week in exchange for the review, if you want :)
17:13:50 <asn> haha thanks for the offer
17:13:56 <asn> let's see how hard this is gonna be
17:14:10 <asn> i have some questions already but i need more time to put them in gitlab
17:14:26 <mikeperry> 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 <mikeperry> juga: have we been able to look at the connectivity relays vs the unmeasured set yet?
17:15:05 <mikeperry> (I can ask later in the sbws channel if you're not here, no worries)
17:15:15 <juga> mikeperry: GeKo has been looking at unmeasured relays
17:15:25 <juga> none of us has been looking at connectivity yet
17:15:32 <juga> was ahf doing that?
17:15:50 <GeKo> i actually have looked at that, too
17:15:52 <mikeperry> 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 <juga> this week planning to look more on the unmeasured relays
17:16:00 <GeKo> last week
17:16:09 <juga> mikeperry: i can search for that later
17:16:30 <mikeperry> it is on the sbws#29701
17:16:41 <GeKo> and found that there is no real difference between torflow and sbws
17:16:44 <juga> i mean, if there's other data for that day
17:16:57 <mikeperry> GeKo: in the unmeasured set?
17:17:34 <ahf> ye, geko looked at that last weke i think
17:17:38 <GeKo> yes
17:17:40 <ahf> ugh, out of sync scrollback
17:17:54 <GeKo> i still need to update the ticket
17:18:19 <mikeperry> ok cool. interesting. I thought historically this mismatch was a problem
17:18:30 <GeKo> it could be
17:18:44 <GeKo> but it is not explaining the bigs gaps alone at least
17:18:51 <GeKo> i'd have to look at my notes
17:18:54 <mikeperry> ok
17:19:30 <mikeperry> 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 <ahf> neat
17:19:48 <dgoulet> \o/
17:20:53 <mikeperry> 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 <mikeperry> 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 <mikeperry> and also for objective 4, I need to go over dgoulet's overload descriptor proposal. hope to do that this week
17:22:25 <mikeperry> and next week is the planning meting. again, dec 7, 15 utc. hope my internet is better this time :)
17:22:25 <ahf> 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 <mikeperry> that is what I am wondering. aurthor fo9und many DNS timeouts
17:23:09 <GeKo> i think that should be getting better
17:23:10 <ahf> and very good with flashflood - and maybe the source code will be home for christmas
17:23:18 <mikeperry> 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 <GeKo> as we badexit relays or get them to fix their setup
17:23:29 <GeKo> but might take a bit of time...
17:24:15 <mikeperry> 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 <ahf> what tooling exists today to deal with the DNS issues?
17:24:52 <ahf> and we have tickets for this? :o
17:24:59 <jnewsome> mikeperry: I don't think it can today. name resolution happens instantaneously
17:25:16 <jnewsome> it doesn't model the actual dns network protocol
17:26:03 <nickm> maybe we can kludge up whatever it uses as a resolver to have a node-dependent probability of failure?
17:26:09 <mikeperry> interesting. it could also be some exit-side TCP timeout too, if that is also instant
17:26:37 <jnewsome> nickm: yeah, probably wouldn't be too difficult
17:26:54 <ahf> does shadow actually do the DNS resolving in a simulation or are they faking the results there too?
17:27:34 <jnewsome> ahf: it doesn't talk to the real network at all, no
17:28:03 <ahf> ok
17:28:08 <mikeperry> 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 <jnewsome> dns resolution is handled inside shadow, using the name<->ip mappings from the simulation config
17:28:15 <ahf> oki
17:29:39 <mikeperry> I think that is it unless others want to bring up more
17:29:59 <ahf> cool
17:30:02 * ahf is good
17:30:48 <ahf> sounds like there is nothing
17:30:51 <ahf> let's end the meeting then
17:30:53 <ahf> thanks all o/
17:30:56 <GeKo> o/
17:30:58 <ahf> #endmeeting