On 7/3/13 4:04 AM, "Jaap Akkerhuis" <[email protected]> wrote:
> > > I'm still trying to figure out how I could tell whether prefetch > makes things better or worse, since the main thing I've learned > from the few DNS cache simulations I've done is that intuition is > not a good guide. > >The net effect it will have is that the average latency querying for >the prefetched domains will be lower I've seen at least one other comment about average latency. Two observations on this: (1) Average is probably not a useful measure here (nor what users experience - they either get a cache hit or a miss.) (2) Comparing anecdotal data isn't likely meaningful in the context of this discussion. The effect of implementing & using HAMMER is that pre-re-fetch of sufficiently popular domains will occur. However, it should be noted that (a) there are a lot of resolvers on the planet, and (b) what is popular does not necessarily correspond to topological proximity. In other words, for a given resolver, there is no guarantee that any particular popular domain will have low latency (and thus that the latency to the user will be low). The impact of pre-re-fetch will be to constrain the upper limit on client resolution latency, and thus to flatten the client latency distribution curve. Additionally, the likelihood of having to retry is reduced (because the only possible loss would be client-resolver, rather than both client-resolver and resolver-authority), further flattening the curve (regardless of how little, the upper bound of latency is reduced). So, I am in favor of this being implemented, and in favor of it being memorialized in an RFC (regardless of WG or individual, standard or informational). Brian _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
