I think firmware size is a perfectly reasonable and sufficient motivation for this draft, but I don't think it can be described as "performance".
--Ben Schwartz ________________________________ From: Christian Amsüss Sent: Wednesday, July 5, 2023 12:17 PM To: Ben Schwartz Cc: Martine Sophie Lenders; c...@ietf.org; draft-ietf-core-dns-over-c...@ietf.org; dnsop; DNS Privacy Working Group Subject: Re: [DNSOP] Next steps: draft-ietf-core-dns-over-coap Hello Ben, picking one of the points in the thread and leaving the rest to another subthread: > > We have a paper on the performance benefits just accepted for CoNEXT, > > which we will cite once it is published. An early pre-print (the final > > paper underwent some major revisions though) is available on arXiv [5]. > > This paper appears to be focused on DNS performance, but DNS is > usually only a small component of overall system performance. In this context, I think a relevant performance metric is firmware size (or, equivalently, network load from firmware updates) -- a metric that is covered in the latest preprint[1] of the same work. While a CoAP plus OSCORE stack is marginally larger in firmware that a DNS plus DTLS stack (and admittedly that's not even accounting for EDHOC that'd also be needed if the DNS server is authenticated with public key cryptography), that is text the application already pulls in, whereas the DTLS component of DNS over DTLS alone already weighs another 20KiB of firmware size. That represents a significant portion of the flash memory available on the relevant microcontrollers. Software complexity (both in terms of LoC and in terms of items on an SBOM) is a factor that improves in parallel to the binary size savings. BR Christian [1]: https://arxiv.org/abs/2207.07486v2 -- To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
