On 01. 04. 21 11:59, Tomas Krizek wrote:
On 31/03/2021 23.28, Rob Sayre wrote:
On Wed, Mar 31, 2021 at 2:16 PM Bill Woodcock <[email protected]> wrote:
…and it’s measuring latency rather than server-side load. I just checked
with our engineers, and it sounds like the server load per-query is more
like 3x-5x higher for the encrypted queries.
Plenty of folks have evaluated the costs here. I'd prefer to discuss data
rather than "checking with engineers". It's not really reasonable to
measure "server load per-query" without a bunch of other data on how the
TLS sessions are being created and maintained.
So, if you have some data you'd like to share with the list, that would
be
most welcome.
We've done some measurements comparing the server-load overhead of DoT
and DoH and while the exact results vary greatly with the client
behaviour, connection management and other parameters, I think 3x-5x
server-load overhead (compared to UDP) is a reasonable expectation. [1]
I will add couple more details about these measurements:
Data show that TLS algorithms in use *and* connection reuse parameters
are crucial. Well-behaved clients over DoT with P256 certificate can be
"only" ~ 2.9 x more expensive (on server) than plain UDP, thanks to the
fact that TCP+TLS connection setup costs get amortized for longer
connections.
For well-behaved clients who do not keep idle connections open the cost
jumps up to 10x.
To generalize for the root server scenario, we need to consider that a
particular well-behaved client should contact root servers rarely, which
means that connection reuse is unlikely. For this reason, I believe that
costs on the server side are likely to be closer to the 10x mark for CPU
costs.
There are limitations to this measurement and generalization, however:
- Measured on stub<->recursive so the generalization might not apply,
especially if recursive<->root has much better connection reuse
conditions (seems extremely unlikely to me)
- No information about bandwidth
- No information about latency
- No information about memory consumption
- No information about DoS potential - we measured well-behaved clients
Petr Špaček @ ISC
Our measurements were for resolvers, but the same methodology and tool
could also used for authoritative server measurements.
From latency point of view, it again depends on connection management
etc., but inevitably, some queries will have the additional cost of
establishing a TCP/TLS handshake. If anyone's interested in measuring
the impact in various network conditions, it's possible to simulate
latency with kernels' Network Emulator [2]. When we've tried that, the
results looked as I've described [3], but the exact outcome depends on
many variables.
[1] - https://indico.dns-oarc.net/event/34/contributions/782/
[2] -
https://dns-shotgun.readthedocs.io/en/stable/replaying-traffic/#emulating-link-latency
[3] - https://dns-shotgun.readthedocs.io/en/stable/latency-histogram
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
