Hi! Our meeting transcript is at:
http://meetbot.debian.net/tor-dev/2017/tor-dev.2017-04-24-16.59.html
Below are the status reports from this week: ==================== Network team meeting pad update notes, 24 April 2017
nick: * was on vacation. * finished consdiffmgr branch (merged today) * reviewed a bit * Refactored directory request api * This week: * aiming to get consdiff implementations mostly done; will depend on compression status. * aiming to review and merge much more, especially compression * Aiming to help others with priorities etc * What am I forgetting? * Concerning topics: * Review backlog. * **Revision backlog**
dgoulet: - Worked on some small 031 tickets, most of them in needs_review or merged. - Finalize the prop224 service hashring and upload descriptor code. (#20657) - Working on adding unit test coverage to #20657 (ongoing work is in branch ticket20657_031_02) - Tickets from the prop224 groundwork are getting merged (#21888). Yay! More ticket to come such as #21979 (load and configure service). This week: - Second round of review on #16861 (mike's branch) - Continue on unit testing for #20657 while adding more and more ticket for upstream merge by pieces. - Resolve some 031 tickets.
ahf: Last week (unordered): Sponsor4: - Monday was easter holiday. - Got #21662, #21663, and #21664 reviewed (first round). - Reviewed #21647 for Nick. - Do coverage runs for the compression code and start adding `LCOV_EXCL_*` in appropiate places and fix tests. This week (ordered): Sponsor4: - Working on cleaning-up things from the #21662, #21663, and #21664 review: currently missing to fix refactoring the different compression test cases into one compression test suite. - Finish coverage fixes. - Fix #22051 (make non-streaming compression API use the streaming compression API). - Handle upper-bound of memory usage in LZMA code (postponed from last week). - Look into next steps for Sponsor4: measurements?
pastly: - so much paper writing - the original "vanilla" Tor scheduler has some configurable limits. - They are never effective in practice (chosen conservatively and never hit). - The vanilla sched is called many times per ms. The intra-tor process queueing times are ~0. Therefore, 100MB (the limits Scheduler{Low,High}WaterMark__) of data never accumulate in the outbufs. - I also plan on removing SchedulerMaxFlushCells__ in favor of a static 1000 (its default). Such a large value makes the sched behave like Tor did before it even had a global sched: one socket at a time. This further cleans the line between the "vanilla" and "kist" schedulers - Maybe max flush cells should be configurable still, but for many other reasons, it isn't useful. - (end for brevity) - They were added to make the scheduler KIST-like. - I plan on removing them. My new scheduler should be used for KIST behavior - As mentioned in previous meetings, it's easy to switch between schedulers
Sebastian: * Have been oxidating. Unfortunately, a big part of the planned rust integration won't be as nice as it could be, because Rust doesn't want to guarantee interface stability for allocing across an FFI border, even if we can ensure that the same allocator is used. * consdiff code compiles on debian stretch, on amd64 (probably x64 too, haven't tested) * Found a couple of bugs in the C consdiff code, nothing major. * Working on final touches, next up is blog post. Will send draft to network-team list before posting.
catalyst: * bug triage. not very many new tickets needed adjusting. * looked at #12930. still working out how the data flow from SMETHOD ARGS to Bridge config lines work, along with quoting, etc. will probably propose some spec revisions to exclude problematic characters from args as a short-term workaround. * looked at snowflake proxy (the browser crowdsourced proxy component) * helped gather info on some macOS Tor Browser 7.0a3 bugs (default search engine, etc.) * wrote regression test for #22034 (GETINFO extra-info/digest/) * obfs4 often fails for me on Tor Browser 7.0a3 in macOS, but meek and obfs3 work. obfs4 in 6.5.2 also works. trying to get more info about this. could learn useful background for improving bootstrap feedback. * a little distracted by buying a house
Mike: Last Week: * Updated #16861 based on dgoulet's review. Let me know if I should squash/rebase again. * Did some work on protocol negotiation for Adaptive Padding * Started learning Rust. It's pretty nice! This week: * More Adaptive Padding, more Rust * Bug Triage
asn: Last week: * About 80% to doing the ed25519 validation. Pushed branch at #22006 . Lots of head beating with crypto math -- Ian helped. * Talked with blockstack people. They will publish a plan for blockstack integration with Tor in two weeks. (ask me for more info) * Reviewed a bunch of prop224 groundwork tickets (#21888) * Did some unittests for my WIP rend circuit crypto branch #21859 * Opened #21969 since it seems the "We're missing descriptors for some of our primary entry guards" bug is still with us. * GSoC stuff Next week: * The Roadmap Email * Finish up the ed25519 validation code #22006 * Take care of some more ed25519 prop224 business (#22052) * Continue work on the e2e circuit stuff (#21859). ETA probably next week EOF
Isabela * Working with teams on roadmaps&dependencies - need help adding tasks related to NSF grants and sponsorR - two dependencies people have related to this team: tbb+ux depend on isis bridges work (already following up with her via email) and maybe on the implementation of the automation for tor launcher (pt selection) * DRL sent us more questions related to our proposal - working on answering those and will have a call with them this week * Will share this week the DRL propsal tasks with all the teams who will be working on them
isis: Last week: * finished OTF work * set up meek-server and also meek reflector on AppEngine for bridgedb channel to new distributor * released draft design of distributor * did status reports and billing and paperwork things This week: * Taking time off because I've not started at Tor yet (also another personal reason)