We quantified this in measurement/modeling studies joint with USC/ISI - TCP connections from stub to recursive need to be held open only on the order of 20 seconds at at time in order to have high reuse rates. One of the measurement sets we used in the study is the DITL set from Level3’s big public DNS server, and these numbers held up. And TCP TFO (almost RFC) and TLS Resume add to the optimizations beyond that. Phillip, what you wrote is extremely oversimplified.
Please see Section 3, Performance Considerations, in draft-hzhwm-dprive-start-tls-for-dns-00.txt. Some of the numbers are in the presentation John Heidemann and Sara Dickinson gave in DPRIVE. Extensive numbers and full methodology are in a tech report referenced by both: ftp://ftp.isi.edu/isi-pubs/tr-688.pdf In addition, I think we're unwise to be debating between mechanisms anyway. Different providers and different end-sites will have different deployment and operational circumstances. A small selection of tools with diverse deployment and operations characteristics are likely to all be used. Allison On Nov 19, 2014, at 1:43 PM, Phillip Hallam-Baker <[email protected]> wrote: > On Wed, Nov 19, 2014 at 12:13 PM, Paul Hoffman <[email protected]> wrote: >> Given that the problem statement for the group is stub-to-resolver, and a >> stub generally uses one resolver, it is quite believable that one would have >> a TCP connection open to the resolver that is reused for future DNS queries. >> After the initial TCP connection to the resolver (which is normally done >> before the first web page request), the speed of the request is the same for >> an open TCP connection as it is for a new UDP "connection". > > > That becomes very problematic when running a big public DNS server. > Basically it would require every client to keep a TCP connection open > permanently. That is a huge load. I have 40 computers with IP in this > house that are used regularly. My network traces are clogged enough > without TCP keepalive packets. > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
