-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi,
It is exactly that option. With some small changes. The draft has a fixed time HAMMER_TIME. Unbound has a hard-coded percentage, 10%, which is not configurable (by choice, no option that hurts). This setting causes an upper bound on the extra work of about 10% and about 10% more traffic towards nameservers (so the prefetch option is not deleterious to others). Authority server owners can influence their prefetch behaviour via the TTL (a larger TTL has a larger 'hammer-time' of 10% of TTL, but also still a larger cache-TTL as well, and also the relative popularity that is necessary to be prefetched goes down as you only need queries inside of a longer time period to be prefetched). We tested this in a large production resolver and found that the benefits are small. Likely when the cache expires there is no more spike in latency for a couple of customers. The cache hits increase modestly, but not spectacularly; some percents more cache hits. In the draft the "touch this" phrase is very funny, however I would prefer implementation-independent phrasing, i.e. 'do not perform prefetch for this element'. Is a draft necessary for this? Best regards, Wouter On 07/02/2013 07:58 AM, Matthijs Mekking wrote: > This sounds a lot like prefetch in unbound, and the configuration > option gives some analysis on increased traffic. > > prefetch: <yes or no> If yes, message cache elements are prefetched > before they expire to keep the cache up to date. Default is > no. Turning it on gives about 10 percent more traffic and load on > the machine, but popular items do not expire from the cache. > > > Also, if the original TTL of the RR is less than STOP * HAMMER_TIME > then the cache entry, it cannot be used anymore and the resolver > should "Break it down". > > Best regards, Matthijs > > On 07/02/2013 03:44 AM, John Levine wrote: >>> We would like to draw your attention to a new draft. >> >> It looks like it should work, assuming that your cache uses the >> existing logic to remember queries in progress so it doesn't >> hammer a record that's already in the process of being >> refetched. >> >> My main observation is that I have no idea what the tradeoffs >> are between the increased DNS traffic and faster responses to >> clients. Have you done simulations or live experiments? >> >> R's, John _______________________________________________ DNSOP >> mailing list [email protected] >> https://www.ietf.org/mailman/listinfo/dnsop >> > > _______________________________________________ DNSOP mailing list > [email protected] https://www.ietf.org/mailman/listinfo/dnsop > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR0ob/AAoJEJ9vHC1+BF+NKMYP/jyEaMqmE4UFWpl8wxHX5QIy aFDIL7Un8Rk9S9ZRR/laLUpo9b4Stfq21lgQeYR75h5MIycSYVX9x8zR3YOXEQsM wsBcA0VxS0J1+4fwJZn1yJ/ZqtdPEIjpP1CD+tKl7sErqkGpcsRQaN5ib62Sayrw eD++QZusEZvtWVG3PjZV7g7PEn2tH7iaoRFhVhqhzc13bzMjp9GahzxrZvgLfnGC 0sDdB1BY8V7GCqfJEMyUEGIeeojlguqu5JXhIMphGW2Chyc8uZguDd/tMwkCVKJc O/NFYf731mg72BpcaY+n2r2bEYrDVEycbYiTblTiEVtyRjdIBxygZaMdKRH0JtaG 6xzbWuRgvFkvd//yGvYvHZi8MuFKEw8TA6OFjjm1x1acGYkq4QNJ7bSqnUK0S1i3 O+Bxw4wfZ2Xz4/Er0r8XDi/iUhBr8f7WVg+X5pBCAXhb9JPhA+AIiZXwoJUI6FTF kiafBu+DPUgpcTJ4Db3MUnedNtAY11FK6QCBLcMnBOxQWZiL7dp+GUO63mRkfkt6 OYfbWn3eEWgYD3tw8iq8RoESQ54cf1X8QzL0kkLeOG2oAxQIrqv/AsMLuKpjGTqJ cEKF3OrqIeG7H0mwNZIW8v3Av2JSICsuOSYYARyGBkvYOt+tBAivlYNaSq/OJLWo GCD2F9UJIVYkHw3V+xaj =dXxa -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
