13:32:49 <nickm> #startmeeting
13:32:49 <MeetBot> 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 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
13:33:03 <nickm> getting a cup of coffee; who's here?
13:33:12 <asn> hello nickm
13:33:17 <Yawning> lurking, been poking at basket
13:34:12 <asn> i'm here mainly about the SponsorR stat branch.
13:34:21 <asn> also because i like meetings.
13:36:18 <Yawning> (asn: I've mostly been ignoring e-mail as well actually)
13:36:55 <asn> Yawning: fwiw, does basket have a threat model?
13:36:57 <teor> apologies, my client dropped out and I didn't see the meeting start
13:36:58 <asn> document?
13:37:18 <Yawning> asn: no, I briefly cover it in the e-mail
13:37:18 <nickm> I have Aaron and Rob in town visiting; we've been talking about peerflow and kist
13:37:19 <asn> 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 <Yawning> I linked the paper >.>
13:37:52 <Yawning> it runs a anti-web fingerprinting defense to the bridge
13:38:10 <Yawning> so it's worthless vs golbal passive adversaries that can do tons of math probably
13:38:29 <asn> so it's useful against adversaries between you and the bridge that are trying to do website fingerprinting.
13:38:32 <asn> ok.
13:38:49 <asn> nickm: so let me start with the status report
13:38:50 <Yawning> yah, doing a real defense requires doing it on the tor level
13:38:52 <asn> nickm: to get things going
13:38:58 <Yawning> which is impractical and stupid expensive
13:39:16 <asn> nickm: over the past week, I answered to a few HS questions over email. some of them are in [tor-dev].
13:39:25 <asn> i also worked on the SponsorR stats code with karsten.
13:39:35 <asn> and I also did some debugging on #8864.
13:39:49 <asn> I wanted to discuss sponsorr stats for a bit (either now or later),
13:39:57 <asn> since we aer supposed to get our code running in a few relays.
13:40:11 <asn> 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 <dgoulet> appears
13:40:38 <asn> because it's hard to run a custom tor with the init script etc.
13:41:01 <asn> 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 <asn> and then give out debs to people.
13:41:46 <asn> 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 <nickm> Do you need more than a few dozen?
13:42:06 <asn> nickm: 20 relays is the number I've been using, but it's arbitrary.
13:42:14 <asn> 10 might also wor. 40 will work better.
13:42:23 <asn> so even if you can't get it merged to tor, it's not that big of a deal.
13:42:33 <asn> we can still get 10 to 20 relays with just a branch (by asking gamambel, etc._)
13:42:42 <asn> but if you feel like merging it, it will be easier.
13:43:02 <nickm> ok, so noted
13:43:27 <teor> Do you need relays with a particular flag/capacity?
13:43:40 <asn> teor: not really. we need hsdirs though.
13:44:05 <asn> nickm: it would be great if you could tell us by tomorrow or friday or so what you think.
13:44:13 <asn> nickm: so that we plan accordingly for monday.
13:44:19 <teor> OK count me in for 2-3 if you can't get it merged
13:44:24 <asn> teor: cheers
13:44:48 <nickm> I'm hoping I can get it reviewed today.  Depends what is on fire
13:44:53 <asn> nickm: brilliant
13:44:55 <asn> nickm: thanks!
13:44:59 <asn> and this is from me.
13:45:11 <asn> next week, I will keep working on sponsorr stats and give some more locve to #8864.
13:45:36 <asn> i've also seen this in two HSes so far:
13:45:36 <asn> Dec 11 13:08:59.000 [notice] We'd like to launch a circuit to handle a
13:45:36 <asn> connection, but we already have 32 general-purpose client circuits
13:45:36 <asn> pending. Waiting until some finish. [268 similar message(s) suppressed
13:45:36 <asn> in last 600 seconds]
13:45:49 <nickm> huh.
13:45:52 <asn> which I think is the result of bad network. but I want to see if it's a bug.
13:45:58 <asn> (the HSes were not mine)
13:46:02 <nickm> maybe there's a rate-limiting bug somewhere.
13:46:16 <asn> traffic rate limitng right? not log message rate limiting?
13:46:40 <nickm> pending circuit creation rate limiting
13:46:51 <asn> hm ac
13:46:52 <asn> ack
13:46:54 <asn> ok, thanks!
13:47:02 <asn> please move on with the meeting
13:47:07 <nickm> 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 <nickm> So, I've been talking to Rob and Aaron.
13:48:39 <nickm> I think it's actually going to be pretty easy to build a KIST prototype, given athena's #9262 work.
13:48:50 <Yawning> nickm: yah
13:49:05 <nickm> 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 <Yawning> was my explanation of how KIST works the otehr day sufficiently accurate?
13:49:34 <dgoulet> I did comment on that yesterday btw #12890
13:49:43 <nickm> I think so!  And Rob's was even more "no, it's simple"
13:49:50 <nickm> dgoulet: thanks!
13:50:45 <nickm> 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 <Yawning> and yeah, the autotuning is sad times, but realistically you'll be cwnd bound
13:51:20 <dgoulet> Yawning: "cwnd"
13:51:21 <dgoulet> ?
13:51:25 <nickm> 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 <Yawning> the tcp congestion window
13:51:51 <Yawning> nickm: every 100 ms may not be all that responsive fwiw
13:52:38 <Yawning> also the ioctls rob gives are linux-isms (Use TIOCOUTQ instead, it's equivalent and more portable)
13:53:21 <dgoulet> Yawning: you should add that to the ticket :)
13:53:59 <Yawning> (the congestion window gets updated every ack basically, or when loss is detected)
13:54:33 <Yawning> so updating not requently enough means you either are not sufficiently responsive to loss, or you underutilize your link
13:54:42 <Yawning> *not frequently enough
13:54:49 <nickm> dgoulet++
13:55:08 <nickm> I'll make the interval tunable and we can experiment
13:55:38 <Yawning> none of our sim tools that aren't shadow can force stuff like packet loss right?
13:55:41 <nickm> 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 <nickm> Yawning: right, unless dgoulet helps get chutney working over "theinternet"
13:56:08 <Yawning> maybe, depends on how much link conditions change in practice
13:56:13 <dgoulet> eheh
13:56:28 <dgoulet> nickm, Yawning: totally doable
13:56:39 <Yawning> underutilizing the link isn't the worst thing in the world, and not being responsive is no worse than current
13:57:09 <Yawning> guess I should comment
13:58:42 * teor is back
13:58:52 <nickm> hi teor
13:59:00 <nickm> And as for peerflow ... wow, it's big.
13:59:03 <Yawning> *goes to comment*
14:04:31 <nickm> It would replace torflow, and make bandwidth measurements much more secure, but looks like a far bit of code
14:04:38 <nickm> and I don't think 100% of the corner cases are figured out.
14:04:50 <nickm> that said, it would be a great idea to patch forflow a little if we can
14:05:02 <nickm> in particular, we should really move to using longer circuits to test the relays in the middle
14:06:39 <nickm> anybody feel like hacking on torflow? :)
14:06:47 <teor> peerflow would also avoid any bias from the location of the bandwidth authorities
14:07:56 <teor> (Of course, the uneven distribution of relays and connections around the world would still have some effect)
14:08:27 <nickm> that's true
14:08:30 <dgoulet> anyone has a link to the paper on that?
14:08:43 <nickm> (anybody feel like cleaning up the experimental peerflow implementation once it's done? ;) )
14:08:54 <nickm> dgoulet: It's still a draft.  If you ask Aaron Johnson he'll probably send you a copy.
14:09:10 <dgoulet> ack
14:09:20 <nickm> 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 <nickm> 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 <teor> I have tuned tor bootstrap until it sings :-)
14:12:51 <nickm> cool!  I would love to see the patch.
14:13:03 <dgoulet> +1
14:13:09 <nickm> that would help a lot with some of the work I'm trying to do on testing
14:13:25 <teor> I am working on grouping it into commits
14:13:55 <nickm> great
14:14:10 <dgoulet> quick update
14:14:49 <teor> 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 <nickm> neat
14:15:21 <dgoulet> 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 <teor> 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 <nickm> 30 is such a big improvement that I'd love to merge the patches soon
14:19:01 <nickm> 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 <teor> 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 <nickm> no problem; I'm just really excited about it
14:21:18 <dgoulet> 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 <asn> what is teor's ticket btw? the one about bootstrapping? :)
14:22:26 <teor> 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 <teor> asn: #13718 and children
14:22:57 <dgoulet> teor: as a starter you have an HS template here :) --> #13934
14:23:05 <nickm> 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 <teor> 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 <asn> teor: thanks :)
14:25:37 <dgoulet> teor: wow love it
14:26:07 <Yawning> there
14:26:12 <Yawning> hope that clears some stuff up
14:26:35 <teor> yeah, it felt like "fix a simple problem" turned into "review an entire codepath for assumptions"
14:26:38 <nickm> thanks Yawning
14:26:47 <Yawning> the windows equivalent of tthe sockopt/ioctls is a single call btw
14:26:50 <nickm> teor: it is certainly a tricky codepath
14:27:02 <Yawning> but it's only avialbe on Vista+
14:27:12 <Yawning> (also in my comment)
14:27:42 <nickm> Yawning: thanks for figuring that out!
14:27:54 <nickm> I think this is going to need testing in the wild and on test networks, but what can I say.
14:28:01 <nickm> maybe it will work great
14:28:03 <Yawning> hey, I'm actually using the KIST trick
14:28:05 <Yawning> :P
14:28:07 <nickm> fortunately, I don't htink it's actually that hard. :)
14:28:10 <nickm> Yawning: how's it working?
14:28:13 <Yawning> so I've given all of this some thought
14:28:22 <Yawning> seems ok for basket, but I haven't ran it in the wild
14:28:27 <Yawning> and I poll on every write
14:28:35 <Yawning> since I need to be responsive to congestion
14:29:25 <dgoulet> Yawning: you do congestion control yourself with basket?
14:29:32 <dgoulet> does that work out well?
14:29:44 <Yawning> (you know what would be a neat gsoc project?  figuring out how to get Tor to play nice with ns-3)
14:30:02 <Yawning> dgoulet: works ok, I use the kist schedule trick to figure out if it makes sense to send padding
14:30:16 <dgoulet> interesting
14:30:18 <Yawning> cuz sending cover traffic when the link is congested is dumb
14:30:47 <Yawning> 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 <Yawning> so I did something smarter
14:31:24 <nickm> oh?
14:31:29 <Yawning> (yes, we have shadow, but ns-2/ns-3 is the standard for certain kinds of research)
14:31:54 <Yawning> well, asking the kernel istead of jsut writing is better >.>
14:32:18 <Yawning> 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 <dgoulet> Yawning: yeah but you ask the kernel before every write?
14:33:10 <Yawning> dgoulet: well, yeah it's a PT, it's not a busy relay
14:33:47 <teor> Yawning: re ns-3, that would be porting tor to the Direct Code Execution environment?
14:33:58 <Yawning> teor: yah, or looking at it
14:34:16 <Yawning> ideally running a full test network
14:34:47 <teor> Do we know how large the gap is?
14:34:52 <Yawning> no idea
14:35:02 <Yawning> last time I was doing this sort fo work, it was called ns-2
14:35:03 <Yawning> :P
14:35:13 <nickm> ok. sounds like we're past meeting and into chatting.  Shall I end?
14:35:33 <dgoulet> yah I think so unless we missed someone badly
14:35:37 <Yawning> ^
14:37:32 <nickm> #endmeeting