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

yaojk <jiankangyao@hotmail.com> Tue, 29 September 2015 21:36 UTC

Return-Path: <jiankangyao@hotmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15B9A1B5182 for <dnsop@ietfa.amsl.com>; Tue, 29 Sep 2015 14:36:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.159
X-Spam-Level:
X-Spam-Status: No, score=-0.159 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DePfUY86OEeF for <dnsop@ietfa.amsl.com>; Tue, 29 Sep 2015 14:36:44 -0700 (PDT)
Received: from SNT004-OMC4S13.hotmail.com (snt004-omc4s13.hotmail.com [65.55.90.216]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E091B517C for <dnsop@ietf.org>; Tue, 29 Sep 2015 14:36:43 -0700 (PDT)
Received: from SNT407-EAS358 ([65.55.90.200]) by SNT004-OMC4S13.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Tue, 29 Sep 2015 14:36:43 -0700
X-TMN: [IvESGNnZONI/zZG8PBwpsCEeDKJiwNhC]
X-Originating-Email: [jiankangyao@hotmail.com]
Message-ID: <SNT407-EAS358C1970FD337AB12A4E9A3B74E0@phx.gbl>
Content-Type: multipart/alternative; boundary="Apple-Mail-5454AF59-AA30-4B17-ABC8-E1636E0407F8"
Content-Transfer-Encoding: 7bit
References: <SNT407-EAS34513D0DB2DB5FEF36F0069B74E0@phx.gbl>
From: yaojk <jiankangyao@hotmail.com>
Date: Wed, 30 Sep 2015 05:45:38 +0800
To: dnsop <dnsop@ietf.org>
MIME-Version: 1.0 (1.0)
X-OriginalArrivalTime: 29 Sep 2015 21:36:43.0275 (UTC) FILETIME=[EF095DB0:01D0FAFE]
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/dNEC12Sn2X3JuumAdOVmD1XSJVA>
Subject: [DNSOP] Fwd: Fw: New Version Notification for draft-yao-dnsop-root-cache-00.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Sep 2015 21:36:49 -0000


Resend. Comments below inline.
Thanks.

Jiankang
> 发件人: yaojk <jiankangyao@hotmail.com>
> 日期: 2015年9月29日 GMT+822:13:55
> 收件人: Shane Kerr <shane@time-travellers.org>
> 抄送: Jiankang Yao <yaojk@cnnic.cn>, dnsop <dnsop@ietf.org>
> 主题: 回复: [DNSOP] Fw: New Version Notification for draft-yao-dnsop-root-cache-00.txt
> 
> 
> 
> 
> 
>> 在 2015年9月29日,17:20,Shane Kerr <shane@time-travellers.org> 写道:
>> 
>> 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.
> 
> If you read my draft more carefully, I think that you will get the different conclusion. It is not same.
> Hammer is to fetch the rr before it expires. Our method is to try to make the current rr live longer while trying to keep it fresh and valid. It is not the pre-fetch specified in hammer. 
> 
> If you like to compare our approach to something, the root data cache is more similar to partial root slave server.
> 
> Our approach is mainly useful for root zone data to try to decrease the access time to root servers.
> 
> The problem trying to be solved is same to the problem solved in dnsop-root-loop-back draft.
> 
> 
>> 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.
> 
> I think that you reach a wrong conclusion here.
> 
> The advantage is that the rr queried is  in root data cache. The data in The root data cache can almost live as long as the data in the root zone slave server.
> 
> 
>> However
>> given the long TTL of root zone entries, such a query will be rare so
>> the benefit is quite small.
> 
> Actually, we use this feature to initiate our design. Since the root data is not likely to be changed, we can have a design similar to ours in the draft.
> 
> 
>> 
>> Cheers,
> 
> 
> Anyway, thanks for your kind comments. I hope that my comments above help you to understand our draft.
> 
> Thanks
> 
> Jiankang Yao
>> 
>> --
>> Shane
>> 
>> On Tue, 29 Sep 2015 12:28:06 +0800
>> "Jiankang Yao" <yaojk@cnnic.cn> wrote:
>> 
>>> 
>>> 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
>> 
>>