Subject: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-root-cache-00.txt

From: "Jiankang Yao" <[email-masked]>
Date: Tue, 29 Sep 2015 12:28:06 +0800

Dear all,

      I submit a draft about Decreasing Fetch time of DNS  Root Data.

   Many DNS recursive resolvers have long round trip times to the DNS
   root server.  It has been an obstacle to increse the performance of
   DNS query.  In order to decrease fetch time of DNS root data, this
   document proposes a new mechanism by improving the mechanism of root
   data cacheing.

       Pls kindly help to review it and give the comments.

      I would also like to apply 10 minutes slot to introduce this idea in the  next IETF meeting

thanks a lot.

Jiankang Yao

From: internet-drafts
Date: 2015-09-29 12:20
To: XiaoDong Lee; Jiankang Yao; Xiaodong Li; Jiankang Yao; Ning Kong; Ning Kong
Subject: New Version Notification for draft-yao-dnsop-root-cache-00.txt

A new version of I-D, draft-yao-dnsop-root-cache-00.txt
has been successfully submitted by Jiankang Yao and posted to the
IETF repository.

Name: draft-yao-dnsop-root-cache
Revision: 00
Title: Decreasing Fetch time of Root Data by Improving the Mechanism of Root Data Cacheing
Document date: 2015-09-28
Group: Individual Submission
Pages: 10
URL:            https://www.ietf.org/internet-drafts/draft-yao-dnsop-root-cache-00.txt
Status:         https://datatracker.ietf.org/doc/draft-yao-dnsop-root-cache/
Htmlized:       https://tools.ietf.org/html/draft-yao-dnsop-root-cache-00

Abstract:
   Many DNS recursive resolvers have long round trip times to the DNS
   root server.  It has been an obstacle to increse the performance of
   DNS query.  In order to decrease fetch time of DNS root data, this
   document proposes a new mechanism by improving the mechanism of root
   data cacheing.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Shane Kerr <[email-masked]>
Date: Tue, 29 Sep 2015 09:20:49 +0000

Jiankang Yao,

I think a simpler approach that works in general is the "HAMMER"
approach proposed by Warren Kumari, Roy Arends, and Suzanne Woolf a
couple of years ago:

https://tools.ietf.org/html/draft-wkumari-dnsop-hammer

Basically the idea is that if a query is made for a RRSET that is near
expiration from the cache, then the resolver will answer normally but
will also try to refresh the TTL by performing another query.

Note that Unbound already implements something like this today, with
the "prefetch" option:

https://unbound.net/documentation/unbound.conf.html

BIND 9 does as well, with "prefetch":

https://deepthought.isc.org/article/AA-01122/0/Early-refresh-of-cache

The "HAMMER" approach works for all domains, not just the root zone,
and doesn't require any separate cache, or indeed any additional state
at all.

The approach you propose will have some small advantage if someone
queries for an entry in the root zone that is not in cache. However
given the long TTL of root zone entries, such a query will be rare so
the benefit is quite small.

Cheers,

--
Shane

On Tue, 29 Sep 2015 12:28:06 +0800

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 29 Sep 2015 07:31:28 -0700

> https://tools.ietf.org/html/draft-wkumari-dnsop-hammer

A huge +1 to this. The proposal in draft-yao-dnsop-root-cache has many 
stability and operational issues that could cause failures, where as 
"look in your cache and fetch things a bit before they expire" has none, 
even if you don't do it right.

> the benefit is quite small.

Yes, exactly.

--Paul Hoffman

---

From: "Joe Abley" <[email-masked]>
Date: Tue, 29 Sep 2015 11:00:54 -0400

Hi Jiankang,

What reason do you have to think that response latency from root servers 
has any measurable impact on end-user experience?

Queries to root servers from individual clients are sent very 
infrequently, in my experience; the TTLs are not short. The probability 
that any client of a real-world resolver gets a delayed response because 
of latency between the resolver and a root server seems vanishingly 
small.

Joe

On 29 Sep 2015, at 0:28, Jiankang Yao wrote:

> URL:            
> https://www.ietf.org/internet-drafts/draft-yao-dnsop-root-cache-00.txt
> Status:         
> https://datatracker.ietf.org/doc/draft-yao-dnsop-root-cache/
> Htmlized:       
> https://tools.ietf.org/html/draft-yao-dnsop-root-cache-00
>
>
> Abstract:
> The IETF Secretariat_______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Jiankang Yao" <[email-masked]>
Date: Wed, 30 Sep 2015 09:23:38 +0800

From: Joe Abley
Date: 2015-09-29 23:00
To: yaojk
CC: dnsop
Subject: Re: [DNSOP] New Version Notification for draft-yao-dnsop-root-cache-00.txt

>has any measurable impact on end-user experience?
I think that there are some papers which explain it.
One observation:
due to the complexity of the network environment, the current quality of access to root service is uneven globally.  For example, CNNIC finds through comprehensive monitoring and analysis that in China the time delay of access to the 13 root servers varies greatly from province to province, showing a difference of up to 200ms for most root servers, and in a number of provinces nearly 60% queries fail to hit the root mirrors deployed in China. 

BTW,
this draft is trying to solve the same problem speicified in draft-ietf-dnsop-root-loopback.
I think that the authors of draft-ietf-dnsop-root-loopback  will have a better explaination than me.

>of latency between the resolver and a root server seems vanishingly 

We use the root data's feature of "the TTLs are not short, the data is not likely to be changed" to initiate our design.

This design in the draft will reduce the load to the root server. Most traffic that might lead to the root server will be lead to the root data cache.

Best Regards
Jiankang Yao

---

From: "Joe Abley" <[email-masked]>
Date: Wed, 30 Sep 2015 09:17:12 -0400

Hi again,

> I think that there are some papers which explain it.

Then some citations would be useful.

To be clear, I'm not having trouble understanding the concept. I just 
don't believe it.

> One observation:
> due to the complexity of the network environment, the current quality 
> of access to root service is uneven globally.  For example, CNNIC 
> finds through comprehensive monitoring and analysis that in China the 
> time delay of access to the 13 root servers varies greatly from 
> province to province, showing a difference of up to 200ms for most 
> root servers, and in a number of provinces nearly 60% queries fail to 
> hit the root mirrors deployed in China.

I believe that, for sure. And I understand the desire to bring the root 
server infrastructure closer to end-users in China, motivated by 
concerns about availability and the problems that would result from 
prolonged non-availability.

However, I think it's controversial to imply that end-user performance 
is substantially improved by the wider (and closer) deployment of root 
zone data. That assertion needs some justification.

For example, a recursive resolver whose clients mainly ask for names 
that end in (say) COM only need to talk to root servers every 172,800 
seconds (that's the TTL on the NS set in the root zone and at the COM 
apex). Even if it takes a really long time to get a response from a root 
server when I need one (e.g. ten seconds, which seems like a high 
estimate), 10/172800 is less than 0.1%, and even in that case it's 
likely that records for popular COM names are independently cached and 
in fact there would be zero impact on end-users that depend on those 
common names even during such an event.

> a better explaination than me.

I had much the same feedback to the authors of that draft. In that case, 
however, it was observed that slaving the root zone was common (if 
perhaps not widespread) practice, and it was worth documenting the 
trade-offs and recommending a consistent approach for those who insisted 
on doing it. That's not the case here.

I think I would need to see a convincing problem statement and 
understand how this proposal provided effective solutions before I could 
support it.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Wed, 30 Sep 2015 06:22:08 -0700

Joe Abley wrote:
> ...
> understand how this proposal provided effective solutions before I
> could support it.

+1.

-- 
Paul Vixie