[p2pi] ALTO service privacy, performance, and architecture

Stanislav Shalunov <shalunov@shlang.com> Sat, 02 August 2008 20:31 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 4E2BE3A695B; Sat, 2 Aug 2008 13:31:54 -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 89F653A6924 for <p2pi@core3.amsl.com>; Sat, 2 Aug 2008 13:31:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.133
X-Spam-Level:
X-Spam-Status: No, score=-2.133 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 0vkXOWDg2ti9 for <p2pi@core3.amsl.com>; Sat, 2 Aug 2008 13:31:51 -0700 (PDT)
Received: from wf-out-1314.google.com (wf-out-1314.google.com [209.85.200.172]) by core3.amsl.com (Postfix) with ESMTP id 454293A68B7 for <p2pi@ietf.org>; Sat, 2 Aug 2008 13:31:50 -0700 (PDT)
Received: by wf-out-1314.google.com with SMTP id 27so1432314wfd.31 for <p2pi@ietf.org>; Sat, 02 Aug 2008 13:32:14 -0700 (PDT)
Received: by 10.142.177.7 with SMTP id z7mr4300587wfe.15.1217709133151; Sat, 02 Aug 2008 13:32:13 -0700 (PDT)
Received: from ?192.168.1.103? ( [67.188.243.194]) by mx.google.com with ESMTPS id 24sm3424889wfc.6.2008.08.02.13.32.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 02 Aug 2008 13:32:12 -0700 (PDT)
Message-Id: <2BC23947-E7E7-4E59-98B2-05E79AE8BA78@shlang.com>
From: Stanislav Shalunov <shalunov@shlang.com>
To: p2pi@ietf.org
Mime-Version: 1.0 (Apple Message framework v926)
Date: Sat, 02 Aug 2008 13:32:11 -0700
X-Mailer: Apple Mail (2.926)
Subject: [p2pi] ALTO service privacy, performance, and architecture
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: multipart/mixed; boundary="===============2084259677=="
Sender: p2pi-bounces@ietf.org
Errors-To: p2pi-bounces@ietf.org

Much time has been spent discussing the operation of a sorting oracle  
or oracles answering questions like "What is the load on this link?",  
"Where did I put my glasses?", "How can I make $100M dollars this  
year?", "What is the link capacity between 1.2.3.4 and 1.2.3.5?", "If  
I were to send a packet to 1.2.3.4 after my next scheduling slice in  
the OS ends and I start to feel pretty, what would be the delay?".  A  
sorting oracle is a useful concept to consider when thinking about the  
system as a whole.  The oracle that answers questions it can't  
possibly answer is not a useful concept.

A literal sorting oracle operated by the ISP will, however, *not* be  
queried by P2P apps and is, therefore, not relevant.

Passing just a few IP numbers to such an oracle is not enough because  
it won't solve the localization problem: chances are none of the few  
are nearby.

Passing the entire swarm or nearly the entire swarm to the oracle is  
not something that we would do in BitTorrent.  I expect other P2P apps  
with users will also not consider this privacy horror seriously.

The sorting needs to happen inside the client.

P2P apps already can easily have a lot of information about the  
network topology.  For example, it is entirely practical to download  
the entire Internet routing table to every client and keep it  
current.  The routing table, is of course, publicly available at a  
looking glass near you.  What P2P apps don't know about the topology  
is what the ISP would actually prefer.

The sort of things that it would be useful to know are:

* Does the ISP prefer local traffic?

* Which IP ranges are local?

* Are there any IP ranges best avoided?  (Mobile or DSL when fiber is  
available, for example.)

Here is an example of a solution that would answer this sort of  
questions.

1. The client discovers an URL using a mechanism similar to BEP 22.   
Say the URL is http://nms.example.net/ip-routing-policy

2. The client checks how long ago it has downloaded this URL.  If more  
than a month ago, downloads again.  The URL is a file containing  
things like:

IP4:1.2.3/24 prefer
IP4:1.2.4/24 avoid
ASN:16 prefer
ASN:18 prefer

Such a solution would be very useful for P2P apps.  ISPs will be able  
to decide how much information they want to reveal about their own  
network topology and business arrangements.  The amount of information  
revealed is the same as through a literal sorting oracle if I'm  
allowed to ask an unlimited number of sorting questions.  Every  
concerned party will thus have an incentive to use this solution.   
Solution is also easy to deploy: for discovery, the ISP will need to  
add one line to a forward DNS zone file; for the actual service, it'll  
need to use a simple script in daily cron to post-process "show ip  
bgp" output or equivalent.

The discovery mechanism would be easy to generalize and use for other  
kinds of discovery.

The ALTO information service would be useful for anything that can  
choose traffic sources/destinations: P2P, CDN, mirror selection, etc.

--
Stanislav Shalunov



_______________________________________________
p2pi mailing list
p2pi@ietf.org
https://www.ietf.org/mailman/listinfo/p2pi