Oooh, I'm sorry, but based on what you write, you must really have skimmed
the paper very lightly.
- The DoHoT solution uses a dnscrypt-proxy stub to actively load-balance
between a pool of DoH servers, accessing them all over Tor.
- Only one of those servers is a Tor Onion server (run by Cloudflare) but
all of the DoH servers, that included, are accessed over Tor.
- With this system, measuring 1.6 million uncached requests, p50 resolution
time over the measured period was 464ms
- With this system, measuring the above + an additional 770k cache-hits,
the p50 resolution time over the measured period was 262ms
- The Onion-Networking DoH server tends to perform least well, with a p50
of 1563ms (your figure?) but it's kept in the pool anyway, as a fallback
- The loadbalancing either defrays or spreads (depending on how you look at
it) the risk of fingerprinting
- The dnscrypt-proxy stub sanitises / makes uniform, all lookups in order
to reduce/remove browser-fingerprinting and instance-to-instance
fingerprinting
- Per the paper: "Any [load-balanced] request that exceeds 10 seconds is
killed, and in a small nod towards performance-over-privacy, the default 30
second "keepalive" is retained to reduce renegotiation-loading upon the
server pool."
In short: the "p50 of just over 400ms for most of the DoH servers" which
you cite for DoH, is *actually *the p50 for the overall DoHoT solution.
464ms *is* the figure for running DoH-over-Tor, using an active stub load
balancer - and 262ms using caching, which puts it into competition with
ODoH - and the paper shows that such performance is comparable to PiHole,
as you will see in the graphs and tables in both the presentation and the
paper.
The section "Potential Confusion" in the paper, spells out - "DoHoT uses
Tor, but is not limited to Onion Networking" - the confusion which you
encountered.
And I still don't know what you would consider to be "acceptable
performance", please?
- alec
On Mon, 19 Jul 2021 at 07:27, Martin Thomson <[email protected]> wrote:
> Based on your paper, it looks like you essentially open a connection to
> the DoH server and then use that for DNS queries. To that end, you would
> drop that connection only when idle. Otherwise you would get connection
> reuse. (I don't know what you have for resumption, but if you are using
> TLS 1.3, that shouldn't hurt performance that much.)
>
> Given that most sites involve a bunch of DNS queries (or hundreds), if you
> are web browsing that means that any circuit setup and connection
> establishment costs are paid about most once for each page view. You still
> pay some latency cost for bouncing around the TOR network, but your tests
> show that while it is large, it's not so bad that it makes the whole thing
> unusable. Your paper shows a p50 of just over 400ms for most of the DoH
> servers compared to 1500ms for DoHoT.
>
> I was speculating about a different baseline, where you might create a new
> connection for every DNS query. At that point, TOR could be as much as
> twice as slow again.
>
> If you go to one connection for each query, which would be required to get
> equivalent privacy to OHTTP, that adds another round trip to each query.
> That could make DoHoT jump to as much as double, depending on what sort of
> proportion of your queries need to go to authoritative servers. 3s per
> query, along with all the extra overheads for circuit and connection setup,
> is much less appealing.
>
> Cloudflare's oblivious DoH results (https://arxiv.org/pdf/2011.10121.pdf)
> are consistent with yours, showing p50 at ~150ms for DoH, ~300ms for ODoH,
> and ~700ms for DoHoT. That's ~2x for ODoH and >4x for DoHoT. And time is
> not the only relevant metric. That used persistent connections, so DoHoT
> has worse privacy than ODoH. And it is far more expensive to terminate
> lots of connections if you were seeking the privacy gains of ODoH/OHTTP.
>
> Paying an extra round trip on a per-query basis is still something you
> could make your own judgment about. Speaking as a browser-maker, even the
> 4x slowdown that comes from TOR with connection reuse would give us pause
> if we were thinking of deploying this for a lot of users.
>
> The overheads of OHTTP/ODoH are not trivial, but when performance is not
> so bad and privacy is better, it's a trade-off worth considering. (We're
> in the process of setting up our own experiments, which will consider the
> effect on web browsing, because doubling DNS query time might sound bad,
> but DNS is still a relatively small component of overall load times.)
>
> Cheers,
> Martin
>
> p.s., I am not aware of any studies on the effect of PiHole on
> performance, but I would be surprised if it were significantly worse than
> baseline. If it is that much worse, that would be a noteworthy result.
>
--
https://alecmuffett.com/about
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
