[tor-project] Network team meeting notes from 24 April 2017
Nick Mathewson
nickm at torproject.org
Mon Apr 24 17:52:40 UTC 2017
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)
More information about the tor-project
mailing list