# Updates from the Network Team, October 2021
**URL:** https://forum.torproject.org/t/updates-from-the-network-team-october-2021/442
**Category:** General Discussion
**Created:** [November 4, 2021, 2:32pm UTC](https://forum.torproject.org/t/updates-from-the-network-team-october-2021/442 "2021-11-04T14:32:50Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@ahf](https://forum.torproject.org/u/ahf)
#### Post date: [November 4, 2021, 2:32pm UTC](https://forum.torproject.org/t/updates-from-the-network-team-october-2021/442/1 "2021-11-04T14:32:50Z")
Welcome to this first monthly update from Tor’s Network Team here on our shiny new Tor Project forum.
These updates will appear monthly and summarize what the team has been working on in the previous month. Today’s update is only from the last two weeks of October, though, as we decided on this new reporting format as an experiment at that time.
The Network Team is responsible for writing the Tor network’s software and supporting tools to test and experiment with the network. In addition to the classic Tor implementation, the team has also recently started working on a Rust implementation of Tor named Arti.
## General Updates on the Team
This month, the team got a new member – a big welcome to eta, who will work on Tor’s Arti project with Nick.
## Tor
The team worked on preparation for the [0.3.5.17, 0.4.5.11, 0.4.6.8, and 0.4.7.2-alpha releases of the Tor software](https://forum.torproject.org/t/release-0-3-5-17-0-4-5-11-0-4-6-8-and-0-4-7-2-alpha/148). The team has recently rotated roles such that David and Alex will generally be trying to take care of the maintenance of [tor.git](https://gitlab.torproject.org/tpo/core/tor/) such that Nick can focus more of his time on the Arti project. As part of the release preparation, backporting of patches took place, and some new patches were introduced to the respective releases to get them ready for release. This work means we were down to around 14 open Merge Requests towards Tor at the end of the release preparation.
After the releases were out, we spent time automating the processes around the preparation of the releases to reduce time spent on this in the future. The work included:
- David wrote a [new Gitlab CI-based pipeline for automatic large parts of the manual processes around the Tor releases (update of GeoIP files, fallback directory indexes, etc.)](https://gitlab.torproject.org/tpo/core/tor-ci-release).
- David wrote a [new Gitlab CI-based pipeline that lets us build reproducible source tarballs from the Git branches in Tor](https://gitlab.torproject.org/tpo/core/tor-ci-reproducible). This new feature will, in the future, allow multiple parties in the team to generate tarballs locally and mutually sign the tarballs with their respective PGP keys.
- Alex wrote a [new Gitlab CI-based pipeline for cross-compilation of Windows binaries on Linux](https://gitlab.torproject.org/tpo/core/tor-ci-win32). The pipeline will run nightly and hopefully catch release critical Windows issues earlier in the process.
As part of the daily work on maintaining Tor, the following newsworthy updates happened:
- David worked together with the Network Health Team on an issue where relays would incorrectly report themselves as being overloaded due to a bug in the DNS subsystem in Tor. The problem was tracked in ticket [tor#40491](https://gitlab.torproject.org/tpo/core/tor/-/issues/40491).
- As part of the above overload issue, the team handled another issue in how Tor reports metrics on DNS requests in [tor#40490](https://gitlab.torproject.org/tpo/core/tor/-/issues/40490).
- Nick wrote a couple of Guard-related proposals found in [Proposal #336](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/336-randomize-guard-retries.md) and [Proposal #337](https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/337-simpler-guard-usability.md) based on conversations with Mike et al.
- Roger and Cecylia from the Anti-censorship Team debugged and fixed a long-time UX issue that affects Tor’s internal Bridgestrap system and users using Tor together with bridges. The team handled this work in [tor#40396](https://gitlab.torproject.org/tpo/core/tor/-/issues/40396) and its respective sub-tickets. Backporting is planned for these issues once the changes have been living in our main branch for a while. Next step, once that ticket is finished, is [tor#40499](https://gitlab.torproject.org/tpo/core/tor/-/issues/40499).
## Arti
The Arti project is The Tor Project’s upcoming implementation of a Tor client in the Rust programming language. This month the big goal was to release Arti version 0.0.1 and get eta up-to-speed on hacking on the Arti codebase. [The team released Arti 0.0.1 ahead of schedule](https://forum.torproject.org/t/arti-0-0-1-is-released-an-embeddable-tor-client-in-rust/281), and you can read the release announcement here.
Some updates for the Arti project from the team:
- General release preparation for [Arti 0.0.1](https://forum.torproject.org/t/arti-0-0-1-is-released-an-embeddable-tor-client-in-rust/281).
- The team dealt with the fallout from [RUSTSEC-2020-0071](https://rustsec.org/advisories/RUSTSEC-2020-0071.html) and [RUSTSEC-2020-0159](https://rustsec.org/advisories/RUSTSEC-2020-0159).
- Added a new target-address API. See: [arti#81](https://gitlab.torproject.org/tpo/core/arti/-/issues/81).
- Allow multiple Arti instances to share a state directory. See: [arti#194](https://gitlab.torproject.org/tpo/core/arti/-/issues/194).
- Rename `tor-client` to `arti-client` to avoid name collision. See: [arti#130](https://gitlab.torproject.org/tpo/core/arti/-/issues/130).
- Added some example code using Hyper to fetch a webpage.
- Clean the client initialization API.
- Improve the circuit isolation API. See: [arti#73](https://gitlab.torproject.org/tpo/core/arti/-/issues/73).
- “Path-bias lite” implementation. See: [arti#185](https://gitlab.torproject.org/tpo/core/arti/-/issues/185).
- `wait_for` overhaul and follow-ups. See: [arti#149](https://gitlab.torproject.org/tpo/core/arti/-/issues/149).
- future-proofing on state serialization. See: [arti#175](https://gitlab.torproject.org/tpo/core/arti/-/issues/175).
- Future-proof CLI and move to clap. See: [arti#206](https://gitlab.torproject.org/tpo/core/arti/-/issues/206).
- Rework top-level documentation.
- Lots of test improvements. Arti’s currently at 80.03% coverage.
## Shadow
The Shadow team is responsible for writing and maintaining the [Shadow network simulator](https://shadow.github.io/) used by the Tor research community and the different internal groups to simulate significant changes before rolling them out in the production network.
This month the team have the following updates:
- Shadow 2.0.0 is now technically released. Rob Jansen is working on some final design documents before announcing the new release more widely. See: [the Shadow Github release page](https://github.com/shadow/shadow/releases/tag/v2.0.0).
- Added an end-to-end CI for testing `tornettools` (the wrapper script to setup, run, and analyze Shadow Tor simulations) in [pull request #44](https://github.com/shadow/tornettools/pull/44).
## Simple Bandwidth Scanner
The [Simple Bandwidth Scanner project (sbws for short)](https://tpo.pages.torproject.net/network-health/sbws/) is used by the Tor network’s Directory Authorities to scan the Tor network for available bandwidth. juga is the maintainer of sbws, and they work closely with both the Network Health Team and the Network Team.
This month’s updates from the sbws project:
- Graph transition from the former bandwidth scanner Torflow to Simple Bandwidth Scanner.
- Follow-up on Simple Bandwidth Scanner deployment on the Directory Authority named gabelmoo.
- Follow-up on Simple Bandwidth Scanner deployment on the Directory Authority called faravahar on whether it reports more relays around 00:00.
- Log attempts to create 2-hop circuits exiting to the exit-local webserver.
## Congestion Control Project
The Congestion Control project is a big cross-team project going on within The Tor Project right now. The Network Team’s Mike Perry leads the efforts, but with help from several other members of The Tor Project, including everybody in the Network Team, Georg from the Network Health Team, Jim from both the Network Team and the Shadow project, juga from the Simple Bandwidth Scanner project, and Hiro from the Metrics Team.
Updates on the Congest Control project this month:
- Jim iterated on the Shadow simulation CI script. We tried using cache volume directly and later Gitlab cache API for storing “full” results, but still debugging.
- Jim experimented with bringing up ephemeral Gitlab CI runners to run more simulations at once using Chameleon Cloud; it seems to work reasonably well.
- Jim created a separate Gitlab project to store the final post-processed data of each simulation and the parameters; simulation runs now use a token to push to this repository automatically.
- We have begun testing and tuning the [congestion control algorithms](https://gitlab.torproject.org/tpo/core/torspec/-/blob/master/proposals/324-rtt-congestion-control.txt) in Shadow. Preliminary test results indicate that `TOR_VEGAS` with the original RTT-adjusted congestion window estimation is the most stable algorithm. Additionally, it appears that the optimal queue length parameters for `TOR_VEGAS` are a function of the TLS connection `outbuf` size and the path length of the circuit, in order to fully utilize all hops in a circuit. Further details on our simulation experiment plans and progress are documented in [our Shadow simulation plan document](https://gitlab.torproject.org/mikeperry/tor/-/blob/cc_shadow_experiments_v2/SHADOW_EXPERIMENTS.txt).
- Hiro worked on patching `tornettools` to generate better throughput graphs based on the last 1 MB of a 5 MB download, instead of the last 500 KB of a 1 MB download. Additionally, we split the `tornettools` graphs by `perfclient` source location (HK/DE). These changes to `tornettools` are helpful to get a clearer picture on the changes in steady-state throughput, and throughput as a function of latency/location.
- We discovered that CircEWMA appears to correctly prioritize circuits in Shadow, so long as we set `TOR_VEGAS` queue parameters large enough to fill all of the output buffers of a path. This is a huge relief, as CircEWMA is necessary to protect `TOR_VEGAS` from cheaters. However, it also means that our `TOR_VEGAS` queue parameters will depend upon path length to ensure that CircEWMA is active and that we fully utilize the path. This will require some patches for the negotiation and Vegas parameterization.
- Jim iterated on workflow for running simulations in Gitlab CI:
## Community
This month some members of the team joined the Community Team training on forum moderation.
## Epilogue
Would you mind letting us know if you found these updates helpful? I’ll try to answer any questions people may have here on the forum in the next few days. If I can’t answer your questions, I’ll try to get somebody from the team to look.
Thanks for reading this far!
---
### Author:  [@ahf](https://forum.torproject.org/u/ahf)
#### Post date: [November 5, 2021, 11:59am UTC](https://forum.torproject.org/t/updates-from-the-network-team-october-2021/442/2 "2021-11-05T11:59:19Z")