13:32:49 #startmeeting 13:32:49 Meeting started Wed Dec 17 13:32:49 2014 UTC. The chair is nickm. Information about MeetBot at http://wiki.debian.org/MeetBot. 13:32:49 Useful Commands: #action #agreed #help #info #idea #link #topic. 13:33:03 getting a cup of coffee; who's here? 13:33:12 hello nickm 13:33:17 lurking, been poking at basket 13:34:12 i'm here mainly about the SponsorR stat branch. 13:34:21 also because i like meetings. 13:36:18 (asn: I've mostly been ignoring e-mail as well actually) 13:36:55 Yawning: fwiw, does basket have a threat model? 13:36:57 apologies, my client dropped out and I didn't see the meeting start 13:36:58 document? 13:37:18 asn: no, I briefly cover it in the e-mail 13:37:18 I have Aaron and Rob in town visiting; we've been talking about peerflow and kist 13:37:19 Yawning: i can see it uses this buflo padding thing, but I'm not sure what security properties this brings to the game. 13:37:39 I linked the paper >.> 13:37:52 it runs a anti-web fingerprinting defense to the bridge 13:38:10 so it's worthless vs golbal passive adversaries that can do tons of math probably 13:38:29 so it's useful against adversaries between you and the bridge that are trying to do website fingerprinting. 13:38:32 ok. 13:38:49 nickm: so let me start with the status report 13:38:50 yah, doing a real defense requires doing it on the tor level 13:38:52 nickm: to get things going 13:38:58 which is impractical and stupid expensive 13:39:16 nickm: over the past week, I answered to a few HS questions over email. some of them are in [tor-dev]. 13:39:25 i also worked on the SponsorR stats code with karsten. 13:39:35 and I also did some debugging on #8864. 13:39:49 I wanted to discuss sponsorr stats for a bit (either now or later), 13:39:57 since we aer supposed to get our code running in a few relays. 13:40:11 our original ideas was to suggest people to run our branch, but this might be hard if we are hoping for many people to do that. 13:40:27 appears 13:40:38 because it's hard to run a custom tor with the init script etc. 13:41:01 nickm: armadev suggested that we could get the code merged in tor (of course, the HS stats config option would be *disabled* by default) 13:41:04 and then give out debs to people. 13:41:46 nickm: i wanted to ask you if you think that's a reasonable thing to do. we are hoping to send the mail asking for volunteers on Monday (hopefully not later than that) 13:41:52 Do you need more than a few dozen? 13:42:06 nickm: 20 relays is the number I've been using, but it's arbitrary. 13:42:14 10 might also wor. 40 will work better. 13:42:23 so even if you can't get it merged to tor, it's not that big of a deal. 13:42:33 we can still get 10 to 20 relays with just a branch (by asking gamambel, etc._) 13:42:42 but if you feel like merging it, it will be easier. 13:43:02 ok, so noted 13:43:27 Do you need relays with a particular flag/capacity? 13:43:40 teor: not really. we need hsdirs though. 13:44:05 nickm: it would be great if you could tell us by tomorrow or friday or so what you think. 13:44:13 nickm: so that we plan accordingly for monday. 13:44:19 OK count me in for 2-3 if you can't get it merged 13:44:24 teor: cheers 13:44:48 I'm hoping I can get it reviewed today. Depends what is on fire 13:44:53 nickm: brilliant 13:44:55 nickm: thanks! 13:44:59 and this is from me. 13:45:11 next week, I will keep working on sponsorr stats and give some more locve to #8864. 13:45:36 i've also seen this in two HSes so far: 13:45:36 Dec 11 13:08:59.000 [notice] We'd like to launch a circuit to handle a 13:45:36 connection, but we already have 32 general-purpose client circuits 13:45:36 pending. Waiting until some finish. [268 similar message(s) suppressed 13:45:36 in last 600 seconds] 13:45:49 huh. 13:45:52 which I think is the result of bad network. but I want to see if it's a bug. 13:45:58 (the HSes were not mine) 13:46:02 maybe there's a rate-limiting bug somewhere. 13:46:16 traffic rate limitng right? not log message rate limiting? 13:46:40 pending circuit creation rate limiting 13:46:51 hm ac 13:46:52 ack 13:46:54 ok, thanks! 13:47:02 please move on with the meeting 13:47:07 maybe a busy HS needs to be able to have more circuits pending at once. Or maybe circuits are getting counted as general that shouldn't be 13:48:16 So, I've been talking to Rob and Aaron. 13:48:39 I think it's actually going to be pretty easy to build a KIST prototype, given athena's #9262 work. 13:48:50 nickm: yah 13:49:05 it turns out that probably no additional scheduling changes are needed: we just need a thread that goes over all the sockets and adjusts their buffer sizes 13:49:08 was my explanation of how KIST works the otehr day sufficiently accurate? 13:49:34 I did comment on that yesterday btw #12890 13:49:43 I think so! And Rob's was even more "no, it's simple" 13:49:50 dgoulet: thanks! 13:50:45 Right now we think we can just have an extra thread that loops over all the sockets once every N seconds to adjust buffer sizes 13:51:02 and yeah, the autotuning is sad times, but realistically you'll be cwnd bound 13:51:20 Yawning: "cwnd" 13:51:21 ? 13:51:25 And make sure that the global write limit is not more than 25% higher than the link capacity, and in theory wr're doing KIST, and we can benchmark how it works 13:51:28 the tcp congestion window 13:51:51 nickm: every 100 ms may not be all that responsive fwiw 13:52:38 also the ioctls rob gives are linux-isms (Use TIOCOUTQ instead, it's equivalent and more portable) 13:53:21 Yawning: you should add that to the ticket :) 13:53:59 (the congestion window gets updated every ack basically, or when loss is detected) 13:54:33 so updating not requently enough means you either are not sufficiently responsive to loss, or you underutilize your link 13:54:42 *not frequently enough 13:54:49 dgoulet++ 13:55:08 I'll make the interval tunable and we can experiment 13:55:38 none of our sim tools that aren't shadow can force stuff like packet loss right? 13:55:41 Rob thinks that we'll get measurably improved results with even a 5sec interval. I'm skeptical, but it doesn't seem like a hard experiment to do 13:56:04 Yawning: right, unless dgoulet helps get chutney working over "theinternet" 13:56:08 maybe, depends on how much link conditions change in practice 13:56:13 eheh 13:56:28 nickm, Yawning: totally doable 13:56:39 underutilizing the link isn't the worst thing in the world, and not being responsive is no worse than current 13:57:09 guess I should comment 13:58:42 * teor is back 13:58:52 hi teor 13:59:00 And as for peerflow ... wow, it's big. 13:59:03 *goes to comment* 14:04:31 It would replace torflow, and make bandwidth measurements much more secure, but looks like a far bit of code 14:04:38 and I don't think 100% of the corner cases are figured out. 14:04:50 that said, it would be a great idea to patch forflow a little if we can 14:05:02 in particular, we should really move to using longer circuits to test the relays in the middle 14:06:39 anybody feel like hacking on torflow? :) 14:06:47 peerflow would also avoid any bias from the location of the bandwidth authorities 14:07:56 (Of course, the uneven distribution of relays and connections around the world would still have some effect) 14:08:27 that's true 14:08:30 anyone has a link to the paper on that? 14:08:43 (anybody feel like cleaning up the experimental peerflow implementation once it's done? ;) ) 14:08:54 dgoulet: It's still a draft. If you ask Aaron Johnson he'll probably send you a copy. 14:09:10 ack 14:09:20 others: If you don't know Aaron, I can introduce you. Etiquette with draft papers is "don't share without permission from authors" 14:11:53 so, anybody else with a thing to talk about today? I'm afraid it's been another one of those weeks for me 14:12:32 I have tuned tor bootstrap until it sings :-) 14:12:51 cool! I would love to see the patch. 14:13:03 +1 14:13:09 that would help a lot with some of the work I'm trying to do on testing 14:13:25 I am working on grouping it into commits 14:13:55 great 14:14:10 quick update 14:14:49 The short version is: tor now bootstraps reliably in 25-30 seconds, from authorities only to reachability self-tests to working exit 14:15:17 neat 14:15:21 on my part, I have to do some SponsorR stuff thus have to put aside patches and hunting ticket down, #8864 is my priority along with two other to simply fix and provide changes file ehhe 14:15:31 If you set some other flags, you can probably cut that down to 10-20 by shaving off a consensus and the self-testing 14:18:36 30 is such a big improvement that I'd love to merge the patches soon 14:19:01 dgoulet: cool; I'd love to know what's up with that one. I'd also like to know if anything weird is up with introduction point stability 14:19:51 I hear you, happy to work on it, but it takes time - maybe this weekend if I get an uninterrupted hour or two :-) 14:20:22 no problem; I'm just really excited about it 14:21:18 nickm: yeah I think there is definitely something with IPs... just the performance measurements I'm doing shows a weird trend with them, I would like also to track their lifetime and close reasons 14:22:03 what is teor's ticket btw? the one about bootstrapping? :) 14:22:26 nickm: chutney may also need some tuning - I may need some help creating quick and comprehensive torrc bootstrap templates. But that can wait until we see if there's a need to be even fatser than 30 14:22:41 asn: #13718 and children 14:22:57 teor: as a starter you have an HS template here :) --> #13934 14:23:05 dgoulet: thanks for following this up. I'm especially concerned if this is correlated to any particular version series of intropoints, or to node stability. 14:24:50 about half of them (the essential ones) are fixed: #13814 #13823 #13839 #13924 #13963 and non-essential #13929 and potentially not needed at all #13928 14:25:25 teor: thanks :) 14:25:37 teor: wow love it 14:26:07 there 14:26:12 hope that clears some stuff up 14:26:35 yeah, it felt like "fix a simple problem" turned into "review an entire codepath for assumptions" 14:26:38 thanks Yawning 14:26:47 the windows equivalent of tthe sockopt/ioctls is a single call btw 14:26:50 teor: it is certainly a tricky codepath 14:27:02 but it's only avialbe on Vista+ 14:27:12 (also in my comment) 14:27:42 Yawning: thanks for figuring that out! 14:27:54 I think this is going to need testing in the wild and on test networks, but what can I say. 14:28:01 maybe it will work great 14:28:03 hey, I'm actually using the KIST trick 14:28:05 :P 14:28:07 fortunately, I don't htink it's actually that hard. :) 14:28:10 Yawning: how's it working? 14:28:13 so I've given all of this some thought 14:28:22 seems ok for basket, but I haven't ran it in the wild 14:28:27 and I poll on every write 14:28:35 since I need to be responsive to congestion 14:29:25 Yawning: you do congestion control yourself with basket? 14:29:32 does that work out well? 14:29:44 (you know what would be a neat gsoc project? figuring out how to get Tor to play nice with ns-3) 14:30:02 dgoulet: works ok, I use the kist schedule trick to figure out if it makes sense to send padding 14:30:16 interesting 14:30:18 cuz sending cover traffic when the link is congested is dumb 14:30:47 the original paper was like "yolo write, the link is congested if it returns EWOULDBLOCK" but that's all sorts of terrible 14:30:57 so I did something smarter 14:31:24 oh? 14:31:29 (yes, we have shadow, but ns-2/ns-3 is the standard for certain kinds of research) 14:31:54 well, asking the kernel istead of jsut writing is better >.> 14:32:18 because waitign for the potentially huge send buffer to fill up before I react to the link being congested isn't great 14:32:43 Yawning: yeah but you ask the kernel before every write? 14:33:10 dgoulet: well, yeah it's a PT, it's not a busy relay 14:33:47 Yawning: re ns-3, that would be porting tor to the Direct Code Execution environment? 14:33:58 teor: yah, or looking at it 14:34:16 ideally running a full test network 14:34:47 Do we know how large the gap is? 14:34:52 no idea 14:35:02 last time I was doing this sort fo work, it was called ns-2 14:35:03 :P 14:35:13 ok. sounds like we're past meeting and into chatting. Shall I end? 14:35:33 yah I think so unless we missed someone badly 14:35:37 ^ 14:37:32 #endmeeting