[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
- [p2pi] ALTO service privacy, performance, and arc… Stanislav Shalunov
- Re: [p2pi] ALTO service privacy, performance, and… Laird Popkin
- Re: [p2pi] ALTO service privacy, performance, and… Y. Richard Yang
- Re: [p2pi] ALTO service privacy, performance, and… Laird Popkin
- Re: [p2pi] ALTO service privacy, performance, and… Stanislav Shalunov
- Re: [p2pi] ALTO service privacy, performance, and… Richard Alimi
- Re: [p2pi] ALTO service privacy, performance, and… Y. R. Yang
- [p2pi] Is P4P protocol public domain so its funct… Reinaldo Penno
- Re: [p2pi] ALTO service privacy, performance, and… Richard Alimi
- Re: [p2pi] Is P4P protocol public domain so its f… Y. R. Yang
- Re: [p2pi] Is P4P protocol public domain so its f… Reinaldo Penno
- Re: [p2pi] ALTO service privacy, performance, and… Stanislav Shalunov
- Re: [p2pi] ALTO service privacy, performance, and… Stanislav Shalunov
- Re: [p2pi] ALTO service privacy, performance, and… Stanislav Shalunov
- Re: [p2pi] ALTO service privacy, performance, and… Stanislav Shalunov
- Re: [p2pi] ALTO service privacy, performance, and… Richard Alimi
- Re: [p2pi] ALTO service privacy, performance, and… Reinaldo Penno
- Re: [p2pi] ALTO service privacy, performance, and… Richard Alimi
- Re: [p2pi] ALTO service privacy, performance, and… Stanislav Shalunov
- Re: [p2pi] ALTO service privacy, performance, and… Richard Alimi
- Re: [p2pi] ALTO service privacy, performance, and… Richard Alimi
- Re: [p2pi] ALTO service privacy, performance, and… Reinaldo Penno
- Re: [p2pi] ALTO service privacy, performance, and… Laird Popkin
- Re: [p2pi] ALTO service privacy, performance, and… Laird Popkin
- Re: [p2pi] ALTO service privacy, performance, and… Richard Alimi
- Re: [p2pi] ALTO service privacy, performance, and… Reinaldo Penno
- Re: [p2pi] ALTO service privacy, performance, and… Stanislav Shalunov
- Re: [p2pi] ALTO service privacy, performance, and… Y. R. Yang
- Re: [p2pi] ALTO service privacy, performance, and… Laird Popkin
- Re: [p2pi] ALTO service privacy, performance, and… Stanislav Shalunov
- Re: [p2pi] ALTO service privacy, performance, and… Satish Raghunath
- Re: [p2pi] ALTO service privacy, performance, and… Stanislav Shalunov
- Re: [p2pi] ALTO service privacy, performance, and… Y. R. Yang
- Re: [p2pi] ALTO service privacy, performance, and… Y. R. Yang
- Re: [p2pi] ALTO service privacy, performance, and… Reinaldo Penno
- Re: [p2pi] ALTO service privacy, performance, and… Reinaldo Penno
- Re: [p2pi] ALTO service privacy, performance, and… Richard Alimi
- Re: [p2pi] ALTO service privacy, performance, and… Laird Popkin
- Re: [p2pi] ALTO service privacy, performance, and… Reinaldo Penno
- Re: [p2pi] ALTO service privacy, performance, and… Laird Popkin
- Re: [p2pi] ALTO service privacy, performance, and… Reinaldo Penno
- Re: [p2pi] ALTO service privacy, performance, and… Robb Topolski
- Re: [p2pi] ALTO service privacy, performance, and… Laird Popkin
- Re: [p2pi] ALTO service privacy, performance, and… Laird Popkin
- Re: [p2pi] ALTO service privacy, performance, and… Marshall Eubanks
- Re: [p2pi] ALTO service privacy, performance, and… Woundy, Richard
- Re: [p2pi] ALTO service privacy, performance, and… Livingood, Jason
- Re: [p2pi] ALTO service privacy, performance, and… Livingood, Jason
- Re: [p2pi] ALTO service privacy, performance, and… Stas Khirman
- Re: [p2pi] ALTO service privacy, performance, and… Stas Khirman
- Re: [p2pi] ALTO service privacy, performance, and… Lars Eggert
- Re: [p2pi] ALTO service privacy, performance, and… Richard Alimi
- Re: [p2pi] ALTO service privacy, performance, and… Lars Eggert
- Re: [p2pi] ALTO service privacy, performance, and… Richard Alimi
- Re: [p2pi] ALTO service privacy, performance, and… Lixia Zhang
- Re: [p2pi] ALTO service privacy, performance, and… Ye WANG