18:01:42 #startmeeting sponsor8 network team meeting 18:01:42 Meeting started Thu Sep 14 18:01:42 2017 UTC. The chair is ahf. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:42 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:01:48 tx 18:01:49 cool! 18:02:09 isabela: do you want to start with #1? 18:02:12 alright, maybe we talk about the montly work planned by activity per activity 18:02:27 so if you look at the storm pad 18:02:33 the first one is 02.3 18:02:49 let me give you some context of how this sponsor work first 18:02:51 :) maybe that helps 18:03:02 :-) 18:03:09 we write a report every quarter about the progress we have made 18:03:37 these 'indicators' are to measure our project impact 18:03:52 we have to provide them when we are writing hte proposal and report on them on a quarterly basis as well 18:04:25 our first report would count for august, september, october and is due at the end of november 18:04:35 so far good? 18:04:39 yep 18:04:49 alright so now lets see activity 02.3 18:04:56 query: These indicators are all things we can check now? 18:04:57 i marked some stuff in blue which i can help with 18:05:16 nickm: depends 18:05:32 ahf: I believe you've started some of these items, but I don't know progress too well 18:05:38 some we will be reporting what we have now to build a baseline for the time we will be measuring the work we are doing in this project 18:05:46 yes! that was sort of what i wanted to have this meeting for 18:06:10 some we will report just a count of stuff we did, so we h ave to do it to report 18:06:30 i've spend a lot of time on getting to understand the android system, "being able to build things myself", getting orbot up and running there where i compile it myself, started figuring out how we measure device information on the device 18:06:59 nice 18:07:14 cool 18:07:19 i've started diving into nick's event emitting information that he wrote in medio august to me this week and thus wanted to have this meeting as well 18:08:14 i feel a bit that i'd like some way to report how we progress - with sponsor 4 i had a lot of pair running with nick, but with this so far i've mostly been doing it on my own, so i wanted to figure out how we do reporting, to get things split into tasks (like we had with sponsor 4), etc. 18:08:26 (if it's not suitable, we can adapt) 18:08:28 how we structure it such that other people have feeling how things are going (and can reproduce it) 18:09:07 1. all tickets should have sponsor8 on it :) 18:09:31 yep 18:10:11 also, how folks does on meeting pad 'sponsor8' indicating that is about it, helps too 18:10:27 but i guess before all that what we need is to define 'what we are doing this quarter' 18:10:43 and list these tasks, i know you started some already, so we can use this meeting to add whatever is missing 18:10:53 and do another quarter plan next quarter and go like that? 18:11:03 network team meeting on mondays? 18:11:20 ? 18:11:25 i dont understand 18:11:30 20:10:49 <+ isabela> also, how folks does on meeting pad 'sponsor8' indicating that is about it, helps too <- is for the network team meetings? 18:11:38 yes 18:11:41 cool 18:12:44 i would like to help with the survey - creating - sending to ppl - giving you the answeres 18:12:56 i would need some help with the questions of course, what we would like to ask 18:13:00 yes, the points right now in blue is something i haven't looked at at all :/ 18:13:07 i can also make a summary of what is at the play store now 18:13:08 it seems a bit i've jumped directly to month #2 18:13:14 that matters for this activity 18:13:15 yes, that would be very nice 18:13:22 ahf: is fine 18:13:32 other than me and ahf, who else is network-team on sponsor8 ? 18:13:34 ahf: work can shift from months to months, is a quarterly report anw 18:13:49 catalyst is working on the erorr reports 18:13:55 *error 18:14:01 isabela: yep, that is very good 18:14:10 i am not sure if the controller too 18:14:12 error reports == O2.5 ? 18:14:20 yes 18:14:59 ok, sorry . keep going? :) 18:15:03 hehe 18:15:08 alright 18:15:22 ahf: looks like you are doing 02.3 then 18:15:41 do you want to work off meeting on the survey questions? i can share a pad at the network team list later and others can help too 18:15:50 (I think I will be putting time into both O2.3 and O2.5, fwiw) 18:16:09 also, do you have any questions on what to do next (and next i mean till end of october) 18:16:19 nickm: cool then that goes to you too :) 18:16:43 also, 18:16:43 sure! I think I'm less great at survey stuff than others, but I'll look if you think it will help 18:16:46 off-meeting is fine 18:16:54 my other question for this activity is the baseline for the indicator we said we will report 18:16:59 i'd like to be part of the survey questions work 18:17:02 let me mark with green 18:17:33 like we have to measure a fixed-size download request 18:17:45 does progress on other stuff count, besides indicator stuff? 18:17:54 yes 18:18:00 we will report progress and indicator 18:18:00 because we're promising stability improvement too, and memory usage improvement, and other stuff 18:18:11 yes 18:18:11 the download speed metric is as observed by our existing infrastructure, or by the Android client on typical wireless connections? 18:18:27 and O2.3.2 looks like it's only speed 18:18:41 i always add an extra sheet with goodies we have accomplished when they are not marked as indicators 18:18:46 catalyst: i dont think that exist yet 18:19:06 nickm: is ok, if we have more metrics i can add to the report too 18:19:36 so, yeah I am looking to see if someone can set this up and how one will be checking this measurements or how i can do that 18:19:41 to be able to report to them 18:23:08 * ahf is reading it 18:23:16 the green part 18:23:46 hm, yes, so that has to be automated somehow and just run 18:24:19 if there is an easy way to do it from an android device we could have a set group of people from our target countries, downloading the same package every quarter and giving us their numbers 18:24:22 and ideally, automated on android. 18:24:30 from a target country. 18:24:44 yes :o 18:24:45 like a .onion url 18:24:54 is easy to find ppl from there to do it once a month 18:24:57 or smoething 18:25:00 *something 18:25:32 could we make a tiny android app where people press 'download' and it fetches a ~10/50/100MB file and reports it to us somehow? 18:25:35 a .onion url that when they open it downloads the fixed-size file and display the time in the screen 18:25:51 or can the people be ourself or? 18:26:02 the person running will email us the number displayed 18:26:08 it can be 18:26:13 but we are not in those countries 18:26:20 anw idk what is the best here :) 18:26:23 just throwing ideas 18:26:36 it can be something we ask them to run and it will just send us the info somehow 18:27:10 this metric seems like a less-than-great way to measure the overhead/stability/app-size stuff 18:27:27 i think it has to be easy if it not ourself - a simple variant could be to have an onion URL where people fetches a 10MB file from? it just seems very flaky to me to do this 18:27:46 a slow circuit on that day would make it go up/down 18:27:50 is there no metric "what is the app size; how long does it take to start and bootstrap" / "what is the cpu usage" / "how much does it crash"? 18:27:58 also if users in our target countries are going to run this measurement we need to figure out how to protect their privacy 18:28:14 catalyst: yes 18:29:02 nickm: we can report the other indicators too 18:29:12 nickm: is fine to add those 18:29:42 "how much does it crash" might be included in O2.4.1 18:29:43 if we feel we should change this one i can work on it with them too 18:29:45 the" app size; startup time; cpu usage " ones should be easy to get 18:30:11 by app size you mean what 18:30:24 how much tor will add to your app size 18:30:30 if you have it embed 18:30:34 Total binary size at rest; total ram usage when running 18:30:50 including libraries that we make the user download and keep 18:31:23 ok 18:32:18 one of our goals is to make the tor "package" for android smaller as well? 18:33:13 if I'm reading the activity descritpion right, I think do 18:33:17 *so 18:33:29 yes 18:33:51 alright 18:34:19 i think we could still report on the donwload speed 18:34:30 yes 18:34:44 that's the hardest one to improve, though :) 18:34:54 yes 18:34:58 we'll see the biggest improvements on the worst hardware on the worst networks 18:35:08 hopefully 18:35:09 since that's where we've spent the least optimizing time so far 18:35:15 right, hopefully :) 18:35:30 so i think it would be worth to have a .onion url that we can ask one person on each target country to do it 18:35:40 and run this measurment for us 18:36:07 it can display the results right there at the url and they just need to copy and send to us 18:36:12 it can send to use automatially 18:37:31 i can set an onion up on some VM, that is no problem 18:37:49 i assume we want it to be a single hop to make the results just a tiny bit more stable? 18:37:58 +1 there 18:38:11 some improvement will be due to HS performance improvements, but that's likely ok 18:38:31 should it just be a "big" file or do we want some content in it? or should it be the application (.apk) itself? 18:38:41 how do we know what country the user is in? do they self-report when running the tool? 18:39:00 ahf: I don't know; what do you thinK? 18:39:09 ahf: no big file 18:39:13 i mean not too big 18:39:19 we dont want to eat the ppl data plan 18:39:27 that costs $$ over there 18:39:45 catalyst: we will contact people from our target countries from this project 18:39:56 catalyst: people we know from the community 18:40:25 this url wont be shared publicly - we will share with folks there and they will tell us the numbers they get 18:40:31 so we're not breaking it down by country? that's probably better privacy-wise 18:40:37 1 MB? i mean, maybe we can just have a set of files there for different people? 1MB, 2MB, 5MB, 10MB, 100MB ? i don't know much about how the data plan structures are in our target countries 18:40:56 catalyst: we need a person from Kenya, Nigeria, Colombia, and India 18:41:08 those are our target countries for this project 18:41:17 cool 18:41:43 ahf: i would say a fixed file size for all countries, 2MB should be ok i think 18:41:47 i would double check that 18:41:58 and i also plan on help find the people etc 18:41:59 :) 18:42:02 ok, i will set a service up with that with a single hop onion 18:42:03 i will talk with the community team 18:42:24 #action ahf sets up single hop onion service with 2 MB file for testing 18:43:42 ok 18:43:52 i added a few at the pad, including this one 18:44:04 maybe we can move on to the next activity? 18:44:16 02.4 18:44:43 yep 18:44:50 Question: Is "reduce battery usage" under this one, or under O2.3? 18:45:02 it also has a survey :) so i hope we can combine all the surveys into a one thing 18:45:14 02.3 18:45:28 combinging them sounds like a good plan 18:45:40 okay. then we should make sure that our battery usage, wakeup/sleep stuff is also measured in O2.3 18:45:56 from what I hear, battery usage is maybe our biggest problem atm 18:46:00 isabela: one thing i'd really like to know from the survey is what kind of devices people are using. i have got a really cheap android device that i use as my "low end" device and a fancy one for my "high end" testing 18:46:04 nickm: +1 18:46:36 during the meeting nick and i had in august we also put our order of looking into things as battery first, then network, then on device storage 18:46:42 would be good to know if battery usage is dominated by CPU or radio transmission 18:46:43 nickm: ok so, app size, startup time, cpu usage, battery usage? 18:46:59 yeah; and possibly "unwanted wakeups" 18:47:04 catalyst: +1 18:47:18 catalyst: my sense is that our biggest battery problem is not paying attention when we're told to sleep 18:47:23 nickm: we have _lots_ of one-second periodic timer events right now, it looks like 18:47:31 catalyst: but I don't think we have measurements to back that up 18:48:04 nickm: you saying the battery problems might be better fixed with the controllers work? 18:48:05 ahf: could you summarize what tools you know of for profiling battery usage details on Android? 18:48:09 ops 18:48:16 nickm: sorry you are right 18:48:23 nickm: battery use is 02.4 not 02.3 18:48:32 "to better control bandwidth and battery use." 18:48:40 is right there at 02.4 title :( 18:49:00 isabela: I'm thinking that we might actually fix the battery problems without much controller work, if the answer to the question is less "obey the application" and more "don't be stupid" 18:49:11 catalyst: yep! i use a tool from 'adb' right now called 'dumpsys' 18:49:11 so I was wondering what category it came under 18:49:28 https://developer.android.com/studio/profile/battery-historian.html + https://developer.android.com/training/monitoring-device-state/index.html is the info sites i've in my notes 18:49:41 i'm cool either way so long as we're measuring battery and improving it 18:49:49 yes 18:50:42 i will keep this indicator 18:50:49 it's the events i started diving into this week: figuring out if i can see a noticable result if i can disable some events as a "dummy test" and ensure that we work nicely with android's own "doze" events. 18:51:01 i think if one or another or both impacts everyone will be happy :) 18:51:37 neat 18:51:44 so we need to add baselines for all these indicators 18:52:09 app size (what is now), startup time (what is now), cpu usage (what is now) 18:52:16 battery usage (waht is now) 18:52:51 i guess for 'startup time' we need one where we look "just" on "little t tor" and one where we look at orfox itself? or should we only focus on the former? 18:53:13 for now little t tor 18:53:31 i will report it separated 18:53:41 because by the time orfox is booting with tor launcher on it 18:53:43 cool 18:53:46 yep 18:53:47 it will be long into the project :) 18:54:37 maybe we can answer the baseline question off meeting? 18:54:48 and we move back to 02.4 :) 18:55:04 so find a baseline for these metrics with current little-t-tor on device via orbot? 18:56:05 hmm i think so, i think this is actually the only way we an measure it on device 18:56:17 *can 18:57:04 agreed 18:57:18 then we run into one of the things i've mentioned a bit with that we have no baseline device right now 18:57:30 so i can do it on a "small" moto-e and a nexus 5x 18:57:39 i have one 18:57:48 then we have to reproduce it using similar devices 18:58:04 true 18:59:33 ahf: i would suggest the following - lets figure out how we collect those measurements 18:59:36 first 18:59:40 than from where 18:59:41 yes! 18:59:45 yep 19:00:03 if we are doing with orbot, lets do it once we can use our own devices and when its working 19:00:22 we can reproduce it with other devices and maybe the folks doing .onion url download test could do this one too 19:00:25 who knows! 19:00:27 :) 19:00:29 yep, agreed 19:01:00 so you were digging into it already? do you want to pick that? 19:01:08 yes 19:01:15 cool 19:01:26 i have android too so if you need anyone testing weird sstuff for you :) 19:01:52 yep, i think most people in our team have android devices - might become useful :-) 19:02:03 i guess for 02.4 main part is to find developers requirements 19:02:27 at least for this quarter 19:02:45 yep. i'm a bit blank on that one 19:02:50 and start with design proposals for it 19:03:11 hmm 19:03:25 i think we can take it offline and do via email lisst as part of the other survey conversation 19:03:40 does anyone knows of any requirements 19:03:53 like folks that might have mentioned needs at tor-dev 19:03:57 or f2f or something 19:04:05 not for controller stuff wrt battery 19:04:13 i think everybody just wants "battery usage should be less" 19:04:24 I think that the controller part will come into play if we find out that there are any tradeoffs 19:04:26 ok but just in general 19:04:27 oh! 19:04:29 i thought of something... 19:04:30 for the controller interface 19:04:56 nickm: yes? 19:04:57 :) 19:04:58 see #23289 19:05:12 that's something where there might be a tradeoff involved 19:05:15 oh, sorry, i was thinking of 2.4.1 19:05:30 ah 19:05:32 we cant do hs stuff for this sponsor 19:05:47 well, hang on a sec and let me know if you agree with this: 19:05:49 2.4 was my initial plan to try out if the doze functionality can be integrated with us 19:05:57 we aren't doing to do hs stuff for this sponsor. 19:06:00 so we can make things "sleep" in tor when the OS tells us to 19:06:39 _but_ if we do faster HS wakeup, then it might be a tradeoff with battery life, which gives us a reason to do battery stuff with controller support 19:06:51 so the application can say what kind of wakeup tradeoff they want 19:08:24 another part of the controller stuff is about managing connections and circuits 19:08:29 yeah 19:08:35 or is that related to what you are saying 19:08:43 maybe? we can find out. 19:08:46 :) 19:08:50 hehe sounds good 19:09:02 #23289 is an example of "something an app dev wants", so i brought it up. we can probably identify non-hs-specific parts 19:09:24 can i ask something? maybe we can use a keyword for the activity the task is related 19:09:32 besides just using the sponsor8 component 19:09:38 yes, please 19:09:40 A02.4 19:09:48 i think david and george is doing quite well with that for their hs project 19:10:26 hm, so use the indicator name for it? should work 19:10:43 so we would have A02.3, A02.4 and A02.5? 19:10:51 yep 19:11:03 nickm catalyst ^^ ? 19:11:08 i'd be more comfortable with memorable names, if that wouldn't make it too hard 19:11:16 hehe 19:11:17 sure 19:11:29 lets give nicknames to these activities :) 19:11:50 like s8-perf, s8-battery, s8-control, s8-bootstrap, s8-errors? 19:11:52 23 = sponsor8-netthroughput, 24 = sponsor8-battery, 25 = sponsor8-error ? 19:12:00 yeep, shorter :-P 19:12:04 heheh 19:12:22 we're going to have to type these a million times :) 19:12:22 what is perf? 19:12:28 perf(ormance) 19:12:32 ahh 19:12:33 :) 19:12:51 ok 19:13:02 i like -> s8-perf, s8-battery, s8-control, s8-bootstrap, s8-errors 19:13:04 better 19:13:11 sorry ahf :P 19:13:38 also this way we can have s8-battery for 02.3 and 02.4 depending on what we are doing 19:13:41 :) 19:14:05 yep, i like the shorter ones much better as well 19:14:40 yeah i like the shorter names (these will be trac keywords?) 19:14:46 yep 19:15:05 yep 19:15:16 alright 19:15:20 almost there people! 19:15:23 sorry is a long meeting 19:15:48 :-) 19:16:09 i would say - go wild and tag things now that we have those and you think a task would be a good fit for the work we need to do here 19:16:18 last one! 19:16:22 02.5 19:16:24 ahh 19:16:30 btw - indicator for controller thing 19:17:59 i think to know of 'reproducible failure' 19:18:06 will be the hard part 19:18:27 or maybe we will learn of those via the survey 19:18:31 i know one thing that's quite reproducible right now is the clock skew hangs 19:18:36 aha! 19:18:51 we should keep countof those, and of course, if we fix those 19:19:04 _where_ it hangs depends on the direction of the skew and whethere there's a cached consensus 19:19:10 many pt failure cases are easy to replicate 19:19:43 ok 19:20:28 can i assume i will be able to know what 'failure' a s8-control ticket is fixing? 19:20:37 if so, i can count these and report 19:21:02 s8-error or s8-bootstrap, you mean? 19:21:16 this is for the controller activity 19:21:17 also i think our goal is less to "fix" and more to "report accurately" 19:21:19 ah 19:21:40 O2.5 though? 19:21:46 or still on O2.4 ? 19:21:48 reporting an error is better than hanging 19:22:01 ok 19:22:07 02.4 indicator unit is : Unit: Application failuresType: Output 19:22:27 O2.5 would seem to be making existing error reporting more useful? 19:22:31 I wonder if we will have a complete list of errors to resolve/report when we start, or whether that will grow as we make work 19:22:36 i guess i will count all new controller we write? 19:23:12 for o2.5 i think we're planning not on writing new controllers, but on reporting more errors/problems under the system we have? 19:23:18 catalyst: yes 19:23:29 catalyst: and the indicator of that is Unit: Error casesType: Output 19:23:41 so is very related to the progress bar you are looking at 19:23:55 and i guess we will report all the error cases we cocver 19:23:57 cover 19:24:06 i think for core tor we can add parameters to the errors we do report, but going into details of recommended solution might get too verbose for a control protocol 19:24:07 nickm: is ok if doesnt grow 19:24:26 nickm: we just need to make sure we are pro-active in collecting feedback/needs 19:24:31 ok 19:24:52 nickm: so we can say, no one is reporting anything to fix anymore, looks like we did it! 19:25:09 but we cant say that without saying how we know no one is 19:25:13 anw 19:27:06 catalyst: maybe the case is that the error msg is not clear 19:27:31 if its better reported there might be no need for 'recommendation for fix' 19:28:39 related is having bootstrap phase names accurately reflect what tor is doing so it's more obvious what things are hanging or taking a long time (right now many of them are lies) 19:28:59 hehe 19:29:00 true 19:29:02 what does it mean that we need to "*confirm* network error reporting" for month #3 ? 19:29:09 i think we might have more insights with the surveys too 19:29:46 hmm 19:30:19 i guess some type of test 19:30:44 sorry i was not necessary the one who wrote this :) but i am the one that needs to help make sense of it 19:30:54 hehe 19:31:00 yep :-) 19:31:16 i dont get the per release 19:31:33 yep 19:31:52 i'm inserting line breaks so i can read this more easily :) 19:32:00 nice 19:32:02 hehe 19:35:04 (what's left to do for today? I'm nearing the end of my meeting-brain) 19:35:31 i feel ya 19:35:41 i think we actually did a good chunk 19:35:56 and should be good 19:36:04 i will follow up via email on this survey stuff 19:36:13 cool. i will continue with the battery work, but will fix the actions for tomorrow. when do we catch up on the survey stuff? 19:36:13 ppl should tag tickets! 19:36:34 and is someone taking "ownership" of the error reporting tasks for now? or do we expect those to happen later in this quarter? 19:36:39 i can get the ball rolling today or latest tomorrow via email 19:36:47 cool 19:37:03 catalyst: do you want to look at the error thing? 19:37:14 catalyst: also, if you want to look at other stuff too 19:37:15 let us know! 19:37:23 i kind of already have been looking at error reporting 19:37:30 yep :) 19:37:55 this clock skew hang stuff seems to be a really big problem 19:38:28 is that something the controller thing can fix? 19:39:35 it's something only core tor can easily fix -- by actually reporting errors rather than sitting there doing nothing (or waiting on excessively long timeouts) 19:40:37 if you want to pick that up, go for it, just tag the ticket with the keyword 19:40:38 we can improve error reporting (mostly parameterizing?) so controllers have an easier time describing possible solutions to the user 19:41:05 we can start fixing things we already know, the survey will help add more stuff - specially what we dont know 19:42:20 are we noting trac keywords on the pad alongside the activities? 19:42:40 i just listed them atthe top 19:42:41 good idea 19:42:48 but i can organize it by activity 19:44:02 i might have done something wrong 19:44:03 cool 19:44:06 :) please review 19:44:07 hehe 19:44:22