I released v1.20210803.0 of dnstt. I changed the major version number to 1 to signify that I do not plan to break compatibility in the future.
- https://www.bamsoftware.com/software/dnstt/#download
- dnstt-20210803.zip (sig, key)
- https://repo.or.cz/dnstt.git/shortlog/refs/tags/v1.20210803.0
- CHANGELOG
The main feature of this release is some parameter tuning for a small improvement in performance in some configurations. See the full post on performance. I’d be grateful for any reports of performance regressions in this new version.
I’m working on Champa, a circumvention tunnel based on AMP cache. Like dnstt, Champa uses a Turbo Tunnel model, with KCP and smux as an inner session layer. While working on Champa, I discovered that adjusting some buffer and window sizes could greatly improve download performance. I suggested that the same idea might help Snowflake, and I spent some time experimenting to see if it could help dnstt as well.
In summary, I was able to improve download speeds, but only in some configurations, and only a little bit. I was encouraged in initial tests with plaintext UDP and without a recursive resolver, which I was able to make go quite fast, even over 1 MB/s. But this is a configuration we don’t care about, because it’s not covert. In a recommended configuration with a recursive resolver and an encrypted transport, I was really only able to speed up Cloudflare/DoT, by about 25%. Quad9/DoT was also sped up, but it was very slow to begin with.
I started by re-running the experiment with v0.20200430.0, the version used in the previous round of performance tests, in order to have a fresh basis of comparison. Since then, the Comcast/DoT server ceased operation, and Cloudflare/UDP went from one of the fastest configurations to the slowest. I repeated the tests with the new v1.20210803.0, which has the performance tweaks.
| resolver | transport | v0.20200430.0 | v1.20210803.0 | change |
|---|---|---|---|---|
| none | UDP | 186.0 KB/s | 332.5 KB/s | +78.7% |
| DoH | 132.7 KB/s | 134.6 KB/s | +1.4% | |
| Cloudflare | DoT | 88.9 KB/s | 112.8 KB/s | +26.9% |
| Cloudflare | DoH | 98.2 KB/s | 97.4 KB/s | −0.7% |
| Comcast | DoH | 75.2 KB/s | 72.7 KB/s | −3.3% |
| UDP | 57.7 KB/s | 70.4 KB/s | +22.0% | |
| PowerDNS | DoH | 35.6 KB/s | 34.9 KB/s | −2.2% |
| Quad9 | DoH | 20.7 KB/s | 31.0 KB/s | +49.4% |
| Quad9 | UDP | 47.5 KB/s | 22.2 KB/s | −53.3% |
| DoT | 44.2 KB/s | 14.4 KB/s | −67.5% | |
| Quad9 | DoT | 0.9 KB/s | 1.6 KB/s | +86.2% |
| Cloudflare | UDP | 0.9 KB/s | 0.8 KB/s | −4.6% |
The Google/DoT, Quad9/DoH, Quad9/UDP rows need some comment. In looking at the second-by-second download rates, we see that in 2 out of 3 trials, Google/DoT was initially going somewhat faster in the new version than in the old version, but then stalled and made no further progress. This was caused by a TCP disconnection (which itself is not unusual when using the Google DoT resolver) followed by a failure to reestablish the connection due to a name lookup error. This could be made more robust, but it does not really bear on bandwidth measurements. In the old Quad9/DoH and the new Quad9/UDP graphs, in 2 of the 3 trials there is a pattern of the download making progress, then stalling, then making progress, then stalling, and so on. I don’t know what may be causing this phenomenon, except to guess that it may be rate limiting on a subset of backend server. In both cases, the 1 trial without the stop-and-start pattern has similar performance as in the other version.
I’ve made the test code and raw data available, so you should be able to reproduce the table and graph, or run your own experiments. You will need git-annex to download a subset of the data files.
git clone https://www.bamsoftware.com/git/dnstt-tests.git
cd dnstt-tests/2021-08-02
git annex get data/*/*.csv
Rscript graphs.R