Taking the fuzz our of client cache results
Hi. I've been running some DNS queries using the probe caches with a view to understanding the latency between the probe cache and the authoritative that I'm interested in. The problem is that there is a fair degree of uncertainty in these measurements because the cache may have to first resolve higher level names in the hierarchy and there is no way of knowing whether the cache had to do this or not. If my query is for www.example.com, it's quite possible that the cache has to first resolve example.com prior to sending the final query for www. This means the measurement may include the cost of getting an answer from .com *and* getting the answer from example.com... sometimes. Depending on how popular example.com is and what other clients are doing with the cache. I'm wondering if there is a way in which we can eliminate this fuzziness? The most obvious way to do this is to ensure the cache is pre-primed with every answer up to, but not including the target name. If we assume the measurement request includes a new "prime cache" flag, then in the presence of that flag the probe could first run a query for something like: cacheprime.example.com substituting the first label with some other value. Alternatively it could first run an NS query for example.com A third alternative is that the creator of the measurement could nominate the priming query as they will have the knowledge needed to get it right. A forth alternative is that the probe could run the query twice - with a nominated delay that is known to exceed the TTL of the target query. In all cases, as soon as the priming query is complete, the probe then runs the target query with a high degree of confidence that the cache only needs to make one round trip to the authoritative server. There is still a small probability that the results will be fuzzy for a variety of reasons, multiple cache choices, anycast caches, super-busy caches, multiple probes using the same cache, but that probability will be very low. Also, a pre-primed query would presumably cost twice as many credits since it's really running two queries. Do others think a primed cache query is of use? And, are there ways of achieving this already? Mark.
Hi Mark, On 2014/05/17 20:24 , Mark Delany wrote:
Also, a pre-primed query would presumably cost twice as many credits since it's really running two queries.
Do others think a primed cache query is of use? And, are there ways of achieving this already?
I'm just focusing on what is already there. If you are using oneoffs, then just running two oneoffs a minute apart should do what you want. If you want a periodic measurement then we have an (apparently undocumented) option to prefix the query with the probe's ID and the current time. This should also give the desired effect. Philip
On 17May14, Philip Homburg allegedly wrote:
If you want a periodic measurement then we have an (apparently undocumented) option to prefix the query with the probe's ID and the current time. This should also give the desired effect.
It helps a little wrt probes sharing caches, but it doesn't help with the timing being distorted by the cache having to fetch parent records. For example, the cache having to ask .com to get example.com name server details. Even if parents have long TTLs (e.g. they come out of a TLD) there is no guarantee that the parent records haven't been evicted due to caching pressure. And yes, periodic is what I should have clarified. Mark.
participants (2)
-
Mark Delany
-
Philip Homburg