09:59:02 #startmeeting Simple Bandwidth Scanner weekly meeting 09:59:02 Meeting started Thu Apr 26 09:59:02 2018 UTC. The chair is pastly. Information about MeetBot at http://wiki.debian.org/MeetBot. 09:59:02 Useful Commands: #action #agreed #help #info #idea #link #topic. 09:59:24 greetings 09:59:33 hi 09:59:56 pad is https://pad.riseup.net/p/6292yqhUOuHC 10:00:17 I finally found your/teor4's email for your proposed SoP schedule 10:01:11 i'd like to make it public, teor is that fine? 10:02:10 many tickets there are for little tor 10:02:11 sure 10:02:53 pastly: tor tickets: https://trac.torproject.org/projects/tor/query?status=!closed&cc=%7Ejuga 10:03:29 Fun stuff, juga :p 10:04:06 teor4: pastly hmm, any recommendation on where to paste those tasks? 10:04:15 otherwise i paste for now in meeting pad 10:04:16 Oh, apologies for contributing to the confusion about 1-line headers vs 4-line. 10:04:39 pad. Maybe we can put them in the sbws wiki after the meeting 10:05:05 pastly: no problem, it's nice that now it's clearer 10:05:37 juga: you could open a top-level ticket for your SoP work, and make all those tickets child tickets 10:06:09 You can make a ticket a child ticket of the parent ticket by setting its ticket field to #parent-id 10:06:19 teor: nice idea, thx 10:06:42 pastly: and maybe i could also create a milestone in sbws with work for sop 10:06:47 Then your tickets will be like all the other network team milestones 10:07:02 juga: sure sounds fine 10:07:13 Yes, that will help pastly and I see how things are progressing 10:07:49 teor: though you were suggesting that in tor trac, right? 10:08:31 juga: I think the tor tickets should be in tor trac, and the sbws tickets should be in the sbws tracker 10:08:54 (Until we decide to move sbws tickets to trac, or move tor away from trac) 10:08:56 teor: right, ok 10:09:40 pastly, teor: on more organizational stuff, i created a project in gh to try to see better what's done, needs to do: https://github.com/pastly/simple-bw-scanner/projects/3 10:09:54 still not sure it helps much 10:10:15 (epic timezone sync at this time people. congrats!) 10:10:35 I'm not sure either. It seems to automatically grab all ticket you open but not anyone else's. 10:11:17 I think it would be better to have a Project that tracks some topic and we manually add tickets to it. Milestones could similarly be used (as I was going to use for the switch to HTTP/s) 10:11:19 pastly: just cause i'm assigning them manually to project, as i do with milestones and tags 10:12:05 pastly: works for me 10:12:06 I also don't want to tell you to not do something that you'd find helpful. 10:12:19 Especially if I don't necessarily have to do much more than just look at it ;) 10:12:48 So right now the Project seems kinda pointless, but if you want to use it go for it. Especially if it's oriented torwards larger multi-ticket goals 10:13:14 k 10:13:46 (thanks asn) PS I think I'd prefer we start at 0930 next week if we like this "morning" (for me) time. 10:14:02 pastly: fine for me 10:14:23 re. sop, what else to discuss? 10:14:39 Because at 1100 UTC I absolutely have to stop and go. 10:14:59 pastly: actually we could make this 30min 10:15:21 I think you were wondering if it was okay to work on something on the schedule right now 10:15:38 right, i see to ways there 10:16:13 And for a variety of reasons, I think yes you absolutely should work on something now even if it isn't scheduled yet. One of those reasons is programmers suck at estimating time 10:17:33 pastly: and i'm sure we'll find way more tasks, and still keeping busy with other tasks... :) 10:17:45 yup yup yup 10:18:02 anything else about sop now? 10:18:05 pastly: you have any other thing to comment on sop? 10:18:13 he, not right now from my side 10:18:16 teor? 10:18:34 juga: if you want to get the bwfile header in the votes in Tor 0.3.4, you should do that task this week 10:18:44 But I don't think it's a priority, it can wait for 0.3.5. 10:18:59 teor: ah, ok, good to know, thx 10:19:11 no I'm good wrt sop 10:19:17 ok 10:19:27 https vs server then? 10:19:29 I am ok with SoP, happy for you to set your own schedule then have us review it 10:19:40 ok 10:20:08 Did anyone read/skim/technically open my doc on the switch to http? 10:20:26 because there're things in trac and things in github, would be fine i have a repo just for my own scheduling 10:20:34 pastly: i started.. 10:21:10 * juga searching for it now... 10:21:13 You can use and abuse the sbws wiki 10:21:18 juga: https://sbws.readthedocs.io/en/latest/proposals/001-switchtohttp.html 10:22:43 I think the first/main thing I'd like feedback on is how to convince ourselves we're measuring 2 relays at a time in a sane way. 10:23:00 so, i'd separate there what's the discassion about server vs http(s) 10:23:12 and how atually the exit relay is choose 10:23:57 also, re server vs http(s) which authentication 10:23:58 Perhaps. I just wanted to get in the correct headspace for figuring out the second half of the document while considering every single moving piece. 10:24:09 pastly: we were always measuring two relays at a time 10:24:32 it's just now, we are being explicit about it 10:25:23 teor: yeah. I don't want to do bucketing like torflow, so I suggest we pick exits in a different way. I propose Idea 1 is the better way (than idea 2). 10:25:41 juga: are you asking how sbws scanners with auth to web servers? 10:26:02 s/with auth/will auth/ 10:26:53 pastly: yes, though not asking, afaik, we're still discussing it 10:27:12 "uses HTTP(S) servers far away from any Tor relay" 10:27:35 currently, sbws servers were assumed to be close to exit 10:28:06 I'm proposing that client auth is optional and performed with client side TLS certificates when required. 10:28:36 Right. We were making that assumption so that we could convince ourselves that we were only measuring 1 relay at a time with current sbws 10:28:41 pastly: I am not sure how I feel about pushing traffic towards fast exits, but I think we might have to do it to measure accurately 10:29:02 I would suggest we choose a "top X" that is large enough for no single operator to control them all 10:29:18 so maybe it should be as large as the top 5% 10:29:57 teor: An Idea 3 could be to pick exits that are 1.25x to 2x as fast as the first hop relay, so that there's an upper bound and we don't always use the absolute fastest X% 10:30:32 equal or higher is fine 10:30:50 bwscanner was doing that, though just a simple ">=" bw 10:31:19 that's easily gameable 10:31:21 #todo add idea 3 for an upper bound on exit speed and/or the simple ">= bw of first hop" 10:31:25 my proposal is that we test the different ideas on the public network, and convince people they are equivalent/better 10:31:55 fun stuff 10:31:59 would an alg for choosing exit remove the idea of the "trusted helper"? 10:32:40 Yes, though my proposal allows for a bwauth to choose to only use specific relays if they really want. 10:32:54 ic 10:33:16 I predict our bwauths will choose to not trust specific relays but may choose to run the webserver themselves 10:33:41 I think we are getting closer to the torflow design, and so people may choose to do the things that torflow was doing 10:33:51 #todo make the exit selection configurable and test the different options 10:34:04 We should check if torflow ran into problems and see if we can fix them in the design stage 10:34:21 yes omg we are so close to being torflow :/ 10:35:01 let's try to don't make the code also looks confusing ;) 10:35:36 so, will then the idea of the sbws server replaced by web server? 10:35:52 or again: choose in conf? 10:36:16 (sorry, i think i might not have follow previous conversations) 10:36:38 juga: I think the sbws server should go away entirely. Instead we should only support HTTP and HTTPS in the variety of configs I list https://sbws.readthedocs.io/en/latest/proposals/001-switchtohttp.html#supporting-many-variations-on-http-s 10:37:08 pastly: ok 10:37:24 I wonder if we can reduce the number of configs to make things simpler 10:37:58 #todo give the directory authority operators config options, and ask them which ones they would run. Remove the ones no-one would run. 10:38:06 teor: most are optional. In most cases you only need a couple 10:38:21 The CDN example is 3 lines. 10:38:24 [destinations.cloudflare] 10:38:25 server_host = sbwsrocks.cdn.cloudflare.com 10:38:27 protocol = https 10:38:50 Re: https://sbws.readthedocs.io/en/latest/proposals/001-switchtohttp.html#supporting-many-variations-on-http-s 10:39:01 Let's support just as many variations as we need 10:40:08 Ok. The only thing that jumps out as possibly unneeded is beign able to specify a list of relays 10:40:32 we should also probably doc all the pros and cons of those options 10:40:39 And maybe the CDN, although stefani is already using a CDN 10:41:03 iirc, there're several tickets in trac aiming to use CDN 10:41:08 And it makes the bastet measurements much more stable 10:41:26 juga: mikeperry doesn't like the idea, but I haven't got the specifics out of him 10:41:44 ok, would be nice to know why then 10:41:54 "unexpected network effects" 10:41:58 It's not clear to me how a CDN is even different at sbws configuration time to using any arbitrary web server. 10:42:29 So I don't see what's so hard about supporting a CDN. As long as the geo-distribution happens at DNS resolution time. 10:42:36 one specific concern is that relays that peer with the CDN get really good bandwidths, but gabelmoo has that issue already without a CDN 10:42:59 pastly: there is nothing hard about a CDN as long as DNS works 10:43:13 and in this case, they have to support HTTPS 1.1 10:43:44 Ok. So as far as I'm concerned there's nothing hard about CDNs in the immediately future. The code is the same. They aren't a special case. It's just up to $someone to decide if they are a good idea. 10:44:48 there'll be probably some work checking how results differ with different methods 10:44:58 teor: is support for HTTPS 1.1 not widespread? 10:45:39 I think it's pretty common. Most CDNs boast of supporting HTTP/2 10:45:58 ok 10:46:15 there's a lot of scope creep and differing opinions in the CDN decision 10:46:32 I'd encourage you to make it possible, and test it, then leave it to the operators to sort out 10:46:51 There is a fastly test URL that we can get a 1 GB file on, if you want 10:46:53 Maybe I should just remove the acronym from the proposal entirely since I'm pretty sure it doesn't matter if cdn.foo.com has 1 A record or 30 10:47:16 are we alo removing the idea the (web) server has to be in same box as the exit (in the CDN case is actually not needed)? 10:47:20 #todo get fastly test URL 10:48:12 juga: yes, because we are abandoning the idea we could ever manage to measure one relay at a time. 10:48:47 * juga feels i was missing discussions this week 10:48:49 ok 10:48:50 I emailed you the URL, but you should talk to tjr about whether to make it public, and getting a 1 GB file on it 10:49:13 #todo modify CDN example so people don't get stuck on "CDN" and try to discuss pros/cons of CDNs when that's not the point of the example 10:49:44 juga: I'm sorry. I think maybe I spent too much time in my head and not enough discussing this stuff 10:49:51 Oh, maybe it is public 10:50:09 And maybe it is tpa (tor project admin) who controls the files on it 10:50:18 juga: I guess to me it seemed obvious or required for us to abandon the "measure 1 relay at a time" idea if we had to stop using sbws servers 10:50:22 teor: i think i actually saw in a ticket when working on bwscanner 10:50:43 Yes, cdn-fastly.torproject.org is definitely public 10:50:53 Because it's in the DNS 10:50:55 (paslty must go in ~9m) 10:51:31 pastly, teor if you don't mind, just say "juga", when talking about something related to this in irc, i'll read it later ;) 10:52:04 +1 10:52:04 ok 10:52:07 pastly: ok, anything else before you leave? 10:52:08 being in different timezones is a bit of work, but we can make it happen 10:52:14 and "teor" is fine for me 10:52:19 either name works 10:52:28 teor: is "teor" a better name to use than teor4? 10:52:40 I tend to default to teor4 since I see it more often talking 10:53:00 Either name works 10:53:14 juga: I'm satisfied with the discussion on switch-to-https so it can stop now if needed 10:53:16 ok 10:54:29 so then fine for me if we finish now, teor? 10:54:41 Ok time to end this meeting. Let's see if those todo things actually worked. Thanks teor and juga! 10:54:42 I'm goof 10:54:49 thanks 10:54:49 I'm good, too 10:54:52 #endmeeting