On Thu, 01 Apr 2021 11:59:26 +0200, 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]
We've published results of server-side CPU and memory at Liang Zhu and John Heidemann. LDplayer: DNS Experimentation at Scale. In _Proceedings of the ACM Internet Measurement Conference_, Boston, Massachusetts, USA, ACM. October, 2018. <https://doi.org/10.1145/3278532.3278544>, <https://www.isi.edu/%7ejohnh/PAPERS/Zhu18b.html>. Including replay of root DNS traffic (DITL) with it's current mix of UDP and TCP and all-TLS. We found (DNS over) UDP and TLS took about the same CPU on our hardware, and pure TCP (without TLS) was actually lower CPU than UDP. See Figure 11 and section 5.2.3 in the paper. (Our code and data is available if you want to reproduce our experiments on your hardware.) IMHO, a bigger operational concern than CPU is actually memory---it's easy to burn through a lot of RAM with TCP and TLS state---see section 5.2.2 and figures 13 and 14 in the paper. It depends a lot on the TCP and TLS timeout you use. Fortunately it's less than 24GB at steady state, which is not a problem for today's hardware. (Although the server should be prepared to early-terminate connections if it's under memory pressure.) Our experiments assume well configured clients and servers. Although not so important for load, optimizations make a huge difference difference for latency. Options like TCP fast open and TLS connection resumption get some of the improvements in QUIC, but over TCP (see <http://dx.doi.org/10.1109/SP.2015.18>, <https://www.isi.edu/%7ejohnh/PAPERS/Zhu15b.html> for the details). I hope people evaluating DNS over QUIC compare against best-configured TCP and not just basic TCP without optimizations. -John Heidemann _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
