Re: [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00

Paul Vixie <paul@redbarn.org> Mon, 20 March 2017 06:26 UTC

Return-Path: <paul@redbarn.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34B9A129683 for <dnsop@ietfa.amsl.com>; Sun, 19 Mar 2017 23:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ssaTryLTPc-o for <dnsop@ietfa.amsl.com>; Sun, 19 Mar 2017 23:26:12 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C295129682 for <dnsop@ietf.org>; Sun, 19 Mar 2017 23:26:12 -0700 (PDT)
Received: from linux-hs2j.localnet (dhcp-148.access.lah1.vix.su [24.104.150.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 392DB61F96; Mon, 20 Mar 2017 06:26:11 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: dnsop@ietf.org
Cc: Lanlan Pan <abbypan@gmail.com>, Warren Kumari <warren@kumari.net>, "fuyu@cnnic.cn" <fuyu@cnnic.cn>
Date: Mon, 20 Mar 2017 06:26:11 +0000
Message-ID: <248334193.jM8B4p3oQd@linux-hs2j>
Organization: Vixie Freehold
In-Reply-To: <CANLjSvXUXVj7yipc5-OtgJpaOAWM8=xtg_pCfemZ1Hrnv9iPLQ@mail.gmail.com>
References: <000f01d29dfe$50b6b190$f22414b0$@cn> <CAHw9_i+bgm=h144Qga1_y2Rdgxgzff1dxeVo2+e4AR-gKtVJ3Q@mail.gmail.com> <CANLjSvXUXVj7yipc5-OtgJpaOAWM8=xtg_pCfemZ1Hrnv9iPLQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gezy8zQ3XTiLB58nOWFFkP-9Cco>
Subject: Re: [DNSOP] FW: New Version Notification for draft-pan-dnsop-edns-isp-location-00
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 20 Mar 2017 06:26:14 -0000

On Monday, March 20, 2017 3:40:46 AM GMT Lanlan Pan wrote:
> At NDSS there is a question that "why not directly use AS number" ? client
> subnet can be maped into AS number, which is used for bgp route at network
> topology.
> 
> My answer was that  AS4134 cover multiple provinces in china, from south
> China to north China, 2000+ kilometers physical distance, also, with long
> latency at network topology.
> 
> As the maxmind ip geo database showed in the slide, my key point is that,
> the "country, province, isp" information can offer the same "network
> topology" information like client subnet.

three eyeball-sets in the city of san francisco might be reachable only 
through either los angeles, or else sacramento, or else salt lake city. 
congestion effects on the long haul links will loom larger than speed-of-
photons-in-fibre in the performance differences a CDN might measure if they 
served the same content to the same user from a data center in los angeles vs. 
sacramento vs. salt lake city.

> We tell Authorative servers that, "I want to know what is most satisfied ip
> address for clients from CHINA, BEIJING, TELECOM at network topology".
> 
> But not "I want to know what is the nearest ip address for clients from
> CHINA, BEIJING, TELECOM at physical topology".

in my example all three eyeball-sets have the same last-mile autnum.

nothing is reliably predictive of last mile performance, except prior 
experience serving similar content to the same client-subnet. estimating the 
client's subnet-size as /24 does some harm to accuracy. estimating it at /28 
does some harm to state-load and state-churn. but anyway you have to serve it 
before you know-- the routing table, the AS path, and the geo-loc are each 
nonpredictive, though each for different reasons.

i am not an ECS fan. far from it! but for what it purports to do, only the 
client's actual subnet will "work" in the live-fire exercise i call "home".

vixie