Re: [p2pi] ALTO Information Export Service

Laird Popkin <laird@pando.com> Wed, 29 October 2008 16:47 UTC

Return-Path: <p2pi-bounces@ietf.org>
X-Original-To: p2pi-archive@ietf.org
Delivered-To: ietfarch-p2pi-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43DD13A681B; Wed, 29 Oct 2008 09:47:42 -0700 (PDT)
X-Original-To: p2pi@core3.amsl.com
Delivered-To: p2pi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF5E3A681B for <p2pi@core3.amsl.com>; Wed, 29 Oct 2008 09:47:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.265
X-Spam-Level:
X-Spam-Status: No, score=-10.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HABEAS_ACCREDITED_COI=-8, IP_NOT_FRIENDLY=0.334]
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 pae+oDRk5VtH for <p2pi@core3.amsl.com>; Wed, 29 Oct 2008 09:47:39 -0700 (PDT)
Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id 618FF3A635F for <p2pi@ietf.org>; Wed, 29 Oct 2008 09:47:39 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 5E850E10B1A; Wed, 29 Oct 2008 12:47:20 -0400 (EDT)
X-Virus-Scanned: amavisd-new at
Received: from dkny.pando.com ([127.0.0.1]) by localhost (dkny.pando.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B+kPzl6l9mYv; Wed, 29 Oct 2008 12:47:19 -0400 (EDT)
Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id E4289E10B10; Wed, 29 Oct 2008 12:47:19 -0400 (EDT)
Date: Wed, 29 Oct 2008 12:47:19 -0400 (EDT)
From: Laird Popkin <laird@pando.com>
To: John Leslie <john@jlc.net>
Message-ID: <1901116948.409151225298839875.JavaMail.root@dkny.pando.com>
In-Reply-To: <20081029154744.GF7530@verdi>
MIME-Version: 1.0
X-Originating-IP: [10.10.20.77]
Cc: p2pi@ietf.org
Subject: Re: [p2pi] ALTO Information Export Service
X-BeenThere: p2pi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: P2P Infrastructure Discussion <p2pi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi@ietf.org>
List-Help: <mailto:p2pi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>, <mailto:p2pi-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

I agree with your analysis, up until the last paragraph.

I don't understand why you say that "policy stated in ASNs is actively misleading" though. Keep in mind that ALTO helps p2p networks find good endpoints, not good routes - that's done by BGP, OSPF, etc., when actually exchanging data. That is, a p2p network knows that it can exchange data between a addresses within (to make up an example) AT&T NYC and Verizon NYC, but it can't control the actual route that the data flows through. Of course, selecting endpoints that have cheap routes between them makes it likely that those cheap routes are actually used, but that's more a matter of the lower layers working properly than anything ALTO allows ISPs to directly express.

- Laird Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "John Leslie" <john@jlc.net>
To: "Laird Popkin" <laird@pando.com>
Cc: p2pi@ietf.org
Sent: Wednesday, October 29, 2008 11:47:44 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] ALTO Information Export Service

Laird Popkin <laird@pando.com> wrote:
> 
> Keep in mind that ASNs are just an option in ALTO (as we're discussing
> it so far), so even if the P2P network uses a public IP to ASN mapping
> database, the ISP can provide their own IP prefix guidance without
> referencing ASNs if they care to.

   Indeed they can -- (by omitting any ASN guidance at all).

   But then, why include the option?

   The advantage of including an ASN option, IMHO, is that a policy can
be stated in a reasonably static manner using ASNs -- provided that the
meaning of those ASNs is clearly "where my routers will forward packets".

   This avoids having to frequently update policy as routing tables change
and having to state policy for hundreds of thousands of CIDR blocks.

   A downside is that ALTO clients may lack up-to-the-minute routing
information when mapping IPs to ASNs. That, IMHO, is something to work
on when the ALTO WG is formed. Several "good-enough" approaches suggest
themselves...

   But if clients are encouraged to use mapping quite unrelated to the
actual routing, then policy stated in ASNs is actively misleading. I
would much prefer not to _design_ misleading policy into ALTO.

--
John Leslie <john@jlc.net>
_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi