Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt

Colm MacCárthaigh <colm@allcosts.net> Fri, 29 January 2010 09:48 UTC

Return-Path: <owner-namedroppers@ops.ietf.org>
X-Original-To: ietfarch-dnsext-archive@core3.amsl.com
Delivered-To: ietfarch-dnsext-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDE9A3A6938; Fri, 29 Jan 2010 01:48:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.677
X-Spam-Level:
X-Spam-Status: No, score=-105.677 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yes6dqdgPxhn; Fri, 29 Jan 2010 01:48:50 -0800 (PST)
Received: from psg.com (psg.com [147.28.0.62]) by core3.amsl.com (Postfix) with ESMTP id BEA9A3A67A3; Fri, 29 Jan 2010 01:48:50 -0800 (PST)
Received: from majordom by psg.com with local (Exim 4.71 (FreeBSD)) (envelope-from <owner-namedroppers@ops.ietf.org>) id 1NanOU-000NJX-SM for namedroppers-data0@psg.com; Fri, 29 Jan 2010 09:44:02 +0000
Received: from [209.85.160.42] (helo=mail-pw0-f42.google.com) by psg.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <colm@allcosts.net>) id 1NanOR-000NIk-6k for namedroppers@ops.ietf.org; Fri, 29 Jan 2010 09:43:59 +0000
Received: by pwi21 with SMTP id 21so1298612pwi.1 for <namedroppers@ops.ietf.org>; Fri, 29 Jan 2010 01:43:58 -0800 (PST)
MIME-Version: 1.0
Received: by 10.141.13.10 with SMTP id q10mr443024rvi.50.1264758238533; Fri, 29 Jan 2010 01:43:58 -0800 (PST)
In-Reply-To: <20100129090542.GB8361@tigger.mamista.net>
References: <6184.1264657589@nsa.vix.com> <48894.1264695230@nsa.vix.com> <50A91B20-5AC1-4819-91ED-E5141F068D48@wiggum.com> <52065.1264699087@nsa.vix.com> <FDD5D1103B8EA4D13C4A2C4C@Ximines.local> <EEAAE4BF-BBA9-4141-BECC-A8440715597F@icsi.berkeley.edu> <58729.1264707908@nsa.vix.com> <6f5b6fe71001281311g6e1fdd05o84ba64837813a6fd@mail.gmail.com> <64415.1264714867@nsa.vix.com> <20100129090542.GB8361@tigger.mamista.net>
Date: Fri, 29 Jan 2010 09:43:58 +0000
Message-ID: <6f5b6fe71001290143k95afb31r1893ffdf13ca5149@mail.gmail.com>
Subject: Re: [dnsext] Re: I-D ACTION:draft-vandergaast-edns-client-ip-00.txt
From: Colm MacCárthaigh <colm@allcosts.net>
To: Martin Barry <marty@supine.com>, namedroppers@ops.ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
List-ID: <namedroppers.ops.ietf.org>
List-Unsubscribe: To unsubscribe send a message to namedroppers-request@ops.ietf.org with
List-Unsubscribe: the word 'unsubscribe' in a single line as the message text body.
List-Archive: <http://ops.ietf.org/lists/namedroppers/>

On Fri, Jan 29, 2010 at 9:05 AM, Martin Barry <marty@supine.com> wrote:
> "Anycast TCP is also in use by a few CDNs and works at least as well as any
> DNS-layer solution. Anycast is stable for minutes or hours at a time, so
> it's rare for two TCP packets to the same destination to reach different
> anycast contributors."

This statement is not supported by data, and does not seem credible.
While anycast is stable, there is no reason to believe that it works
at least as well as a DNS-layer solution.  At my previous employer
(Joost.com) we ran a small private CDN for P2P seeding, video and
image and distribution, using both anycast and DNS tricks. DNS tricks
proved to be at least twice as good at lowering network latencies,
though granted we were not particularly well-peered and had only a
handful of transit providers.

Anycast directionality is essentially out of the hands of the service
provider and the behaviour depends on such things as upstream transit,
filtering and peering policies. In contrast, DNS tricks are
controllable on a very granular basis. The biggest problem with DNS
tricks is that there may be a anti-correlation between the resolver's
locality and its users - which this I-D is specifically an attempt to
fix.

> Conversely "dns-tricks" can be, and are, used by those who don't meet the
> above criteria. The only limitations are having authorative servers capable
> of applying the "tricks".

+1

-- 
Colm