Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
On Wed, 3 Jul 2013, Warren Kumari wrote: prefetch: 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. Doh, sorry, I was not aware that Unbound did this. I'd like to recognize this in the draft, any idea who actually suggested it / added it to the code? I'm pretty sure Wouter added the code, but I'm not sure who came up with the idea. Probably multiple people. It's a feature you really need when running DNS(SEC) on the stub or else you're continuously dealing with waiting on DNS. I believe the option was added to unbound 1.4.2 released around march 2010, and the RHEL and Fedora packages enabled prefetching then as well. So it's been there for over three years! Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
W.C.A. Wijngaards (wouter) writes: > > Yes I wrote the code and say so. (Not sure how that is better than > reading the source). Results, anecdotally, are very modest. It does > remove latency spikes for popular names. What does the latency spike translate to in terms of extra traffic (clients) ? A thundering herd effect ? Congestion ? Considering how many tricks modern browsers have up their sleeves (including prefetching data linked on a page), I'm wondering how the two interact. I've always mentioned the expiring RR prefetch option to be a cool feature of Unbound, but in reality, what does it mean for users ? > Aside, I agree that prefetching before the TTL expires is overly > aggressive. If it mitigates other issues... > But lengthening the TTL is worse (for DNSSEC rollovers > TTLs MUST expire, or the signatures become bogus). :) P. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, On 07/03/2013 11:56 PM, Warren Kumari wrote: My question earlier still stands: does Unbound do what HAMMER says (waits for a request before refreshing the cache) or does it just refresh the cache automatically? The Unbound doc is unclear (at least to me). Yes, it waits for a request before refreshing the cache. The request is the excuse to bother the authority server, since it could pretend the entry had fallen out of the cache. And also the request indicates a continued interest (the item is still popular). It was also simpler to implement :-) So, prefetch also prefetches fairly impopular names, that have about 10 queries per TTL. And one query hits the 10% last of the TTL. For a TTL of 3600, getting about 10 queries in 3600 seconds would statistically make you hit one query in the last 10% (a little) often. And that is one query per 360 seconds, which is fairly impopular, but it is prefetched. >> Those are pictures. Source code, or developer assurance, or it >> didn't happen ( to badly bastardize a phrase that the kids these >> days use ). Yes I wrote the code and say so. (Not sure how that is better than reading the source). Results, anecdotally, are very modest. It does remove latency spikes for popular names. > It *appears* to me from looking at the source that Unbound triggers > upon an incoming query (basically what HAMMER suggests). I should > note that this is the first time I have looked at the Unbound > source, and so it is entirely possible that I'm missing something. Yes, it trigger upon an incoming query. > There is also a PREFETCH_EXPIRY_ADD which I don't really > understand: > > /** * seconds to add to prefetch leeway. This is a TTL that > expires old rrsets * earlier than they should in order to put the > new update into the cache. * This additional value is to make sure > that if not all TTLs are equal in * the message to be updated(and > replaced), that rrsets with up to this much * extra TTL are also > replaced. This means that the resulting new message * will have > (most likely) this TTL at least, avoiding very small 'split * > second' TTLs due to operators choosing relative primes for TTLs (or > so). * Also has to be at least one to break ties (and overwrite > cached entry). */ #define PREFETCH_EXPIRY_ADD 60 > > I must admit that I'm somewhat shaky on much of the above, it would > be great if someone who is more familiar with the architecture / > code could comment/ Prefetch happens before the TTL expires, x seconds before. You can determine x in many different ways, a fixed value works for very highly popular names (i.e. draft submitter's employer), but for less popular ones (i.e. my employer :-) ), prefetch can also work but needs a bigger value, that is why I chose a fraction instead of absolute value. Unbound uses x + 60 to replace 'old' RRsets when the new reply comes in. This x+60 is subtracted from the TTL in the cache for RRsets to determine if they are 'old' (with respect to the reply for this prefetch). Because if it used exactly x, then the cache could contain a remaining cache TTL x+1 for another RRset that forms up the reply from cache that we would use for further queries. So we could only answer for 1 second extra because we refused to update some RRs that make up the response (but we updated the RR that was about to expire). The value 60 is one that I picked with a similar idea as when you talked about tilting at the windmills of small TTLs, but it does not actually prevent the zone operator from choosing small TTLs, it stops the hammer system from generating such small TTLs in the cache from the larger TTLs that the authority system sends. The defensive code about NS records you refer to is to make sure that this system can handle a zone operator change without 'sticking' to the old operator; e.g. 'if x+60 > remaining cache TTL of NS RRset' then we must go up to the parent operator, even though the child NS has not expired yet. Aside, I agree that prefetching before the TTL expires is overly aggressive. But lengthening the TTL is worse (for DNSSEC rollovers TTLs MUST expire, or the signatures become bogus). Best regards, Wouter -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJR1TFiAAoJEJ9vHC1+BF+NcuUP/1u6cB9LVEwoEHmucXoPE8Tt z5frpV0xbfn6BaR0dvilorOHFr3KUe7HLa9ZRYHSaTDGqsYGqwmQC8HPx55r3sPn 9znMMxvAuX46BaAiLA1+7BEjKe96ubRkGZT6Lgt7C0UYcZfICG2U+CHOUVlPUJhU pBDRq+o0fwhrP4Wx9L8aGtQwy+cFoxMi1sgQNSwji3QXZjzw+5ioV43CGx8HnAFM 09triotHJtD/weHWbk5RksQ9Fh0ncWXXFwiIPbKFwAKs28UDqP+fCWBwG5CeooNM ruxuHRuJ7TEpWmPpB0WZfiCS6eIkGxr1ZaH0YKzni1+EC9qkpw7ziaUo19svZEEU QxSWKOfBXOgWbJQvFj9BBKmKojv7ShVfzpe20czmsPdXuZsVwqWfOPeVtuV7lqJQ 6SP38LZvBE9qs4rZiXvvROYZyU3yqtyhp9i5K2aMncR64gsAtWCScR1diJWPLpWP P55mHEmGaeu4xUsrvu49JMihDdxgSZYmZM4HdcUlShlzKYYOTuqKRh8C5Kzk7Ybq FK5OOSyc4r8+kSRAmPtzj4pNf1cR/Te
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
On Jul 3, 2013, at 5:14 PM, Paul Hoffman wrote: > On Jul 3, 2013, at 2:01 PM, "John Levine" wrote: > > 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. >> >>> My question earlier still stands: does Unbound do what HAMMER says >>> (waits for a request before refreshing the cache) or does it just >>> refresh the cache automatically? The Unbound doc is unclear (at least >>> to me). >> >> If it did it automatically, I'd expect a lot more than 10% more >> traffic. I enabled it on my not terribly busy server and I see >> numbers that look like they're in the 1% range: >> >> Jul 03 14:23:21 unbound[40669:0] info: server stats for thread 0: 47798 >> queries, 20108 answers from cache, 27690 recursions, 242 prefetch >> Jul 03 15:23:21 unbound[40669:0] info: server stats for thread 0: 53322 >> queries, 20319 answers from cache, 33003 recursions, 291 prefetch >> Jul 03 16:23:21 unbound[40669:0] info: server stats for thread 0: 55260 >> queries, 20697 answers from cache, 34563 recursions, 272 prefetch >> > > Those are pictures. Source code, or developer assurance, or it didn't happen > ( to badly bastardize a phrase that the kids these days use ). It *appears* to me from looking at the source that Unbound triggers upon an incoming query (basically what HAMMER suggests). I should note that this is the first time I have looked at the Unbound source, and so it is entirely possible that I'm missing something. It seems that worker_handle_request() in worker.c has the interesting bits. >From what I can tell, the worker will only have this sort of request if it was >initiated by an incoming query. Horrendous pseudocode seems like: worker_handle_request() if answer_from_cache: if prefetch_ttl_expired: reply_and_prefetch() /** Reply to client and perform prefetch to keep cache up to date */ reply_and_prefetch() reply() /* create the prefetch in the mesh as a normal lookup without * client addrs waiting, which has the cache blacklisted (to bypass * the cache and go to the network for the data). */ /* this (potentially) runs the mesh for the new query */ mesh_new_prefetch(worker->env.mesh, qinfo, flags, leeway + PREFETCH_EXPIRY_ADD); There is also a PREFETCH_EXPIRY_ADD which I don't really understand: /** * seconds to add to prefetch leeway. This is a TTL that expires old rrsets * earlier than they should in order to put the new update into the cache. * This additional value is to make sure that if not all TTLs are equal in * the message to be updated(and replaced), that rrsets with up to this much * extra TTL are also replaced. This means that the resulting new message * will have (most likely) this TTL at least, avoiding very small 'split * second' TTLs due to operators choosing relative primes for TTLs (or so). * Also has to be at least one to break ties (and overwrite cached entry). */ #define PREFETCH_EXPIRY_ADD 60 I must admit that I'm somewhat shaky on much of the above, it would be great if someone who is more familiar with the architecture / code could comment/ W > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Do not meddle in the affairs of wizards, for they are subtle and quick to anger. -- J.R.R. Tolkien ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
Those are pictures. Source code, or developer assurance, or it didn't happen ( to badly bastardize a phrase that the kids these days use ). I looked at the unbound source code. It prefetches when it's responding to a query, code in daemon/worker.c. The code is considerably complicated by defensive code to deal with the situation where the parent of the record to be prefetched has changed since the record was originally fetched. (Feel free to check my work.) That's probably worth mentioning in the I-D. There is a separate option to prefetch DNSSEC key records. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY "I dropped the toothpaste", said Tom, crestfallenly. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
On Jul 3, 2013, at 2:01 PM, "John Levine" wrote: 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. > >> My question earlier still stands: does Unbound do what HAMMER says >> (waits for a request before refreshing the cache) or does it just >> refresh the cache automatically? The Unbound doc is unclear (at least >> to me). > > If it did it automatically, I'd expect a lot more than 10% more > traffic. I enabled it on my not terribly busy server and I see > numbers that look like they're in the 1% range: > > Jul 03 14:23:21 unbound[40669:0] info: server stats for thread 0: 47798 > queries, 20108 answers from cache, 27690 recursions, 242 prefetch > Jul 03 15:23:21 unbound[40669:0] info: server stats for thread 0: 53322 > queries, 20319 answers from cache, 33003 recursions, 291 prefetch > Jul 03 16:23:21 unbound[40669:0] info: server stats for thread 0: 55260 > queries, 20697 answers from cache, 34563 recursions, 272 prefetch > Those are pictures. Source code, or developer assurance, or it didn't happen ( to badly bastardize a phrase that the kids these days use ). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
>>>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. >My question earlier still stands: does Unbound do what HAMMER says >(waits for a request before refreshing the cache) or does it just >refresh the cache automatically? The Unbound doc is unclear (at least >to me). If it did it automatically, I'd expect a lot more than 10% more traffic. I enabled it on my not terribly busy server and I see numbers that look like they're in the 1% range: Jul 03 14:23:21 unbound[40669:0] info: server stats for thread 0: 47798 queries, 20108 answers from cache, 27690 recursions, 242 prefetch Jul 03 15:23:21 unbound[40669:0] info: server stats for thread 0: 53322 queries, 20319 answers from cache, 33003 recursions, 291 prefetch Jul 03 16:23:21 unbound[40669:0] info: server stats for thread 0: 55260 queries, 20697 answers from cache, 34563 recursions, 272 prefetch ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
On Jul 3, 2013, at 10:30 AM, Warren Kumari wrote: > > On Jul 2, 2013, at 1:58 AM, Matthijs Mekking wrote: > >> This sounds a lot like prefetch in unbound, and the configuration option >> gives some analysis on increased traffic. >> prefetch: >>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. > > Doh, sorry, I was not aware that Unbound did this. I'd like to recognize this > in the draft, any idea who actually suggested it / added it to the code? My question earlier still stands: does Unbound do what HAMMER says (waits for a request before refreshing the cache) or does it just refresh the cache automatically? The Unbound doc is unclear (at least to me). --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
well, for a moment, I did have to think about this draft being a joke or not. But the acronym was perfect. :) On 7/3/2013 1:30 PM, Warren Kumari wrote: On Jul 2, 2013, at 1:58 AM, Matthijs Mekking wrote: This sounds a lot like prefetch in unbound, and the configuration option gives some analysis on increased traffic. prefetch: 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. Doh, sorry, I was not aware that Unbound did this. I'd like to recognize this in the draft, any idea who actually suggested it / added it to the code? 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". I got a few off-list questions asking about the odd naming (and I also remember the IETF Diversity thread on Discuss). For folk who have no idea what the hell we are on about: http://www.youtube.com/watch?v=GbKAaSf6e10 http://www.youtube.com/watch?v=otCpCn0l4Wo 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. Hmm. Probably worth mentioning. 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? Nope. This doesn't really change the average very much, but it should help decrease the jitter / spikes for the unlucky few who hit the resolver just as the cache entry expires. The draft specified HAMMER_TIME as a time, not a percentage because: A: I wanted to use the phrase HAMMER_TIME (and STOP HAMMER_TIME!) :-P B: The main "issue" that the draft tries to solve is increased resolution times for the unlucky few who hit the resolver when the record has just expired. In order to decrease the added load caused by this, I chose a default that is somewhat longer than a "bad" resolution experience with a few failures along the way. C: STOP was added to prevent doing a cache-fill request on every recursive request for records that have TTL of < HAMMER_TIME. D: I was (tilting at windmills and) trying to get folk to not use TTLs of < a few seconds in the records :-) From reading the unbound prefetch thing, I suspect maybe a better solution would be: HAMMER_TIME defaults to 2 (or 1 or something) seconds If the original TTL is < HAMMER_TIME, then only do the cache-fill when the TTL is 10% of the original TTL. This means that: if HAMMER_TIME is 2 and the original TTL is 600 seconds -- the auth servers will see approximately 0.3% additional traffic. if HAMMER_TIME is 2 and the original TTL is 60 seconds -- the auth servers will see approximately 3.3% additional traffic. if HAMMER_TIME is 2 and the original TTL is 1 seconds -- the auth servers will see approximately 10% additional traffic. W R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- "Go on, prove me wrong. Destroy the fabric of the universe. See if I care." -- Terry Prachett ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
On Jul 2, 2013, at 6:07 AM, Antoin Verschuren wrote: > Signed PGP part > Op 01-07-13 23:43, Warren Kumari schreef: > > Hi there, > > > > We would like to draw your attention to a new draft. > > I like this draft and concept, but how new is it? Not very :-) > It's good to be documented though. > Thank you! INd a(and RFCs) to me seem like a reasonable place to document implementation advice, warnings, etc, regardless of if they require protocol change or affect interoperability. > I feel like when a recursive resolver has implemented HAMMER, and > HAMMER_TIME is set to zero, we have an existing sticky resolver. Yup. > > One thing that fails though for this analogy to be complete, is how > iterative the "cache fill" query will be. > If a record from a zone is about to expire, but it still has a valid > NS set for that zone in it's cache, will it ignore or use that NS set > to issue the iterative query? > If it does use it, thereby being a full sticky resolver, it will > create less DNS traffic for static delegated zones, as it does not hit > the parent again. > If it doesn't, and ignores the NS set for the zone in it's cache, and > re-queries the parent, it will hit the parent harder than when it did > not implement HAMMER, and probably create more DNS traffic than > without HAMMER. > > I feel this needs to be clarified in the draft. Yup, good point. W > > > - -- > Antoin Verschuren > > Technical Policy Advisor SIDN > Meander 501, PO Box 5022, 6802 EA Arnhem, The Netherlands > > P: +31 26 3525500 M: +31 6 23368970 > Mailto: antoin.verschu...@sidn.nl > XMPP: antoin.verschu...@jabber.sidn.nl > HTTP://www.sidn.nl/ > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf Warren Kumari war...@kumari.net signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
On Jul 2, 2013, at 1:58 AM, Matthijs Mekking wrote: > This sounds a lot like prefetch in unbound, and the configuration option > gives some analysis on increased traffic. > prefetch: > 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. Doh, sorry, I was not aware that Unbound did this. I'd like to recognize this in the draft, any idea who actually suggested it / added it to the code? > > > 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". > I got a few off-list questions asking about the odd naming (and I also remember the IETF Diversity thread on Discuss). For folk who have no idea what the hell we are on about: http://www.youtube.com/watch?v=GbKAaSf6e10 http://www.youtube.com/watch?v=otCpCn0l4Wo > 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. Hmm. Probably worth mentioning. >> >> 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? Nope. This doesn't really change the average very much, but it should help decrease the jitter / spikes for the unlucky few who hit the resolver just as the cache entry expires. The draft specified HAMMER_TIME as a time, not a percentage because: A: I wanted to use the phrase HAMMER_TIME (and STOP HAMMER_TIME!) :-P B: The main "issue" that the draft tries to solve is increased resolution times for the unlucky few who hit the resolver when the record has just expired. In order to decrease the added load caused by this, I chose a default that is somewhat longer than a "bad" resolution experience with a few failures along the way. C: STOP was added to prevent doing a cache-fill request on every recursive request for records that have TTL of < HAMMER_TIME. D: I was (tilting at windmills and) trying to get folk to not use TTLs of < a few seconds in the records :-) >From reading the unbound prefetch thing, I suspect maybe a better solution >would be: HAMMER_TIME defaults to 2 (or 1 or something) seconds If the original TTL is < HAMMER_TIME, then only do the cache-fill when the TTL is 10% of the original TTL. This means that: if HAMMER_TIME is 2 and the original TTL is 600 seconds -- the auth servers will see approximately 0.3% additional traffic. if HAMMER_TIME is 2 and the original TTL is 60 seconds -- the auth servers will see approximately 3.3% additional traffic. if HAMMER_TIME is 2 and the original TTL is 1 seconds -- the auth servers will see approximately 10% additional traffic. W >> >> R's, >> John >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- "Go on, prove me wrong. Destroy the fabric of the universe. See if I care." -- Terry Prachett ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
On 7/3/13 4:04 AM, "Jaap Akkerhuis" 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 DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
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 at the cost of a (max 10% with current values) bigger cache size and added traffic. I'm running unbound with verbosity 1 logging. Any suggestions? Verbosity 4 will give details and lots of debugging info as well so you don't really want to run like that for a long time. My intuition was (based on experiences from measurements on caches) that the effect wouldn't been spectacular. That was confirmed by the people who asked us for it. jaap ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
On 07/02/2013 10:25 PM, John Levine wrote: I don't see the real-world benefit of this. Fine: you don't need implement it. There are enterprise environments where the round-trip times are more significant to them than they seem to you in your enterprise environment. 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. I'm running unbound with verbosity 1 logging. Any suggestions? Well, first you have to define "better" and "worse" for your environment. :) (And no, I'm not being snarky.) ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
>> I don't see the real-world benefit of this. > >Fine: you don't need implement it. There are enterprise environments where the >round-trip times are more >significant to them than they seem to you in your enterprise environment. 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. I'm running unbound with verbosity 1 logging. Any suggestions? ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
On Jul 2, 2013, at 11:06, Paul Hoffman wrote: > There are many drafts and RFCs produced by the IETF that do not "impact > interoperability". This document describes an operational issue. That seems > kind of appropriate for the DNSOP WG, yes? Since you asked, no. [0] I don't see an operational issue, not in the DNS operational sense. If there is an application that is so sensitive to delay, it can pre-fetch data as it needs, this doesn't need to be pressed into the infrastructure. As other messages indicate, implementations already do this. It's fine for an individual submission to document what they do, what's the need for a WG review/development/stamp of approval? [0] The charter is wide open to this, still I would say no. It's worth noting that the charter's latest milestone is February 2008. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
On Jul 2, 2013, at 6:44 AM, Edward Lewis wrote: > First, I don't see why this draft exists in the IETF. How does this impact > interoperability? There are many drafts and RFCs produced by the IETF that do not "impact interoperability". This document describes an operational issue. That seems kind of appropriate for the DNSOP WG, yes? > Further, this draft is hinting at a mixed signal. In an era where operators > are rushing to deploy RRL because of what appears on the surface to be overly > aggressive clients, the document is telling cache servers that they ought to > be (slightly) overly aggressive. I get that this is *slightly* overly > aggressive and that the use here is "benign" (chuckle if you want), but, > well, 131 is still over the limit (of 130 kph). And intent is immaterial > when I see a query thrown my way. RRL is being deployed because of botnets, which are not clients at all: they simply use the DNS protocol. The draft is not for things that are overly aggressive at all. > Why is this important? I looked at one popular name, just to pick one for > the sake of an email message (not a whitepaper). The TTL on an A record is > 300 and my dig reported it took 19ms to get a response from an authoritative > server. I.e., the domain wants to change the A frequently but also has a > fast authoritative infrastructure. 19ms is less than one-half of one percent > of one percent of 300, if I plug that into an "efficiency" I'm dividing: > > 300 / 300.019 = 99.993% > > I don't see the real-world benefit of this. Fine: you don't need implement it. There are enterprise environments where the round-trip times are more significant to them than they seem to you in your enterprise environment. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
On Jul 1, 2013, at 10:58 PM, Matthijs Mekking wrote: > This sounds a lot like prefetch in unbound, and the configuration option > gives some analysis on increased traffic. > > prefetch: > 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. I thought unbound's prefetch kept the cache full all the time, not just when a nearly-expired name is gotten from the cache. HAMMER specifically grabs only when a name is used again close to its expiration. Or am I misunderstanding the unbound documentation? --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
First, I don't see why this draft exists in the IETF. How does this impact interoperability? Further, this draft is hinting at a mixed signal. In an era where operators are rushing to deploy RRL because of what appears on the surface to be overly aggressive clients, the document is telling cache servers that they ought to be (slightly) overly aggressive. I get that this is *slightly* overly aggressive and that the use here is "benign" (chuckle if you want), but, well, 131 is still over the limit (of 130 kph). And intent is immaterial when I see a query thrown my way. Why is this important? I looked at one popular name, just to pick one for the sake of an email message (not a whitepaper). The TTL on an A record is 300 and my dig reported it took 19ms to get a response from an authoritative server. I.e., the domain wants to change the A frequently but also has a fast authoritative infrastructure. 19ms is less than one-half of one percent of one percent of 300, if I plug that into an "efficiency" I'm dividing: 300 / 300.019 = 99.993% I don't see the real-world benefit of this. On Jul 1, 2013, at 17:43, Warren Kumari wrote: > Hi there, > > We would like to draw your attention to a new draft. > If describes a simply optimization that, with minimal to no state, keeps > popular records in recursive server's caches. > > W > > Begin forwarded message: > >> From: internet-dra...@ietf.org >> Subject: New Version Notification for draft-wkumari-dnsop-hammer-00.txt >> Date: July 1, 2013 5:40:44 PM EDT >> To: Roy Arends , Suzanne Woolf , Warren >> Kumari >> >> >> A new version of I-D, draft-wkumari-dnsop-hammer-00.txt >> has been successfully submitted by Warren Kumari and posted to the >> IETF repository. >> >> Filename: draft-wkumari-dnsop-hammer >> Revision: 00 >> Title:Highly Automated Method for Maintaining Expiring >> Records >> Creation date:2013-07-01 >> Group:Individual Submission >> Number of pages: 5 >> URL: >> http://www.ietf.org/internet-drafts/draft-wkumari-dnsop-hammer-00.txt >> Status: http://datatracker.ietf.org/doc/draft-wkumari-dnsop-hammer >> Htmlized:http://tools.ietf.org/html/draft-wkumari-dnsop-hammer-00 >> >> >> Abstract: >> This document describes a simple DNS cache optimization which keeps >> the most popular records in the DNS cache. >> >> > > No man is an island, But if you take a bunch of dead guys and tie them > together, they make a pretty good raft. >--Anon. > > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis NeuStarYou can leave a voice message at +1-571-434-5468 There are no answers - just tradeoffs, decisions, and responses. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] New Version Notification for draft-wkumari-dnsop-hammer-00.txt
Hi Antoin, On Jul 2, 2013, at 6:07 AM, Antoin Verschuren wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Op 01-07-13 23:43, Warren Kumari schreef: >> Hi there, >> >> We would like to draw your attention to a new draft. > > I like this draft and concept, but how new is it? > It's good to be documented though. Not to speak for Warren, but this is why I was willing to work on a draft. > I feel like when a recursive resolver has implemented HAMMER, and > HAMMER_TIME is set to zero, we have an existing sticky resolver. > This is the idea, yes. > One thing that fails though for this analogy to be complete, is how > iterative the "cache fill" query will be. > If a record from a zone is about to expire, but it still has a valid > NS set for that zone in it's cache, will it ignore or use that NS set > to issue the iterative query? > If it does use it, thereby being a full sticky resolver, it will > create less DNS traffic for static delegated zones, as it does not hit > the parent again. > If it doesn't, and ignores the NS set for the zone in it's cache, and > re-queries the parent, it will hit the parent harder than when it did > not implement HAMMER, and probably create more DNS traffic than > without HAMMER. > > I feel this needs to be clarified in the draft. This is the other reason for a draft :) I know this has been in the field in various forms, but AFAIK those questions haven't really been asked across teams of implementors or groups of operators. If they have, I'm happy to reduce my own ignorance and others' by documenting accordingly. Suzanne ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
