Re: [alto] Problems with the Alto problem statement

Laird Popkin <laird@pando.com> Fri, 14 November 2008 23:56 UTC

Return-Path: <alto-bounces@ietf.org>
X-Original-To: alto-archive@ietf.org
Delivered-To: ietfarch-alto-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF63928C13B; Fri, 14 Nov 2008 15:56:21 -0800 (PST)
X-Original-To: alto@core3.amsl.com
Delivered-To: alto@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19C4F3A680C for <alto@core3.amsl.com>; Fri, 14 Nov 2008 15:56:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.151
X-Spam-Level:
X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[AWL=0.114, 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 nVi-6Guvhmoa for <alto@core3.amsl.com>; Fri, 14 Nov 2008 15:56:20 -0800 (PST)
Received: from dkny.pando.com (dkny.pando.com [67.99.55.163]) by core3.amsl.com (Postfix) with ESMTP id C8FF13A67E1 for <alto@ietf.org>; Fri, 14 Nov 2008 15:56:19 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by dkny.pando.com (Postfix) with ESMTP id 9CE2DE10B91; Fri, 14 Nov 2008 18:56:19 -0500 (EST)
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 hXe0rlLnLWEO; Fri, 14 Nov 2008 18:56:08 -0500 (EST)
Received: from dkny.pando.com (dkny.pando.com [10.10.60.11]) by dkny.pando.com (Postfix) with ESMTP id 3A7C3E10B90; Fri, 14 Nov 2008 18:56:08 -0500 (EST)
Date: Fri, 14 Nov 2008 18:56:08 -0500
From: Laird Popkin <laird@pando.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>
Message-ID: <395625583.102321226706968208.JavaMail.root@dkny.pando.com>
In-Reply-To: <367173192.102301226705452461.JavaMail.root@dkny.pando.com>
MIME-Version: 1.0
X-Originating-IP: [10.10.20.77]
Cc: alto@ietf.org
Subject: Re: [alto] Problems with the Alto problem statement
X-BeenThere: alto@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Application-Layer Traffic Optimization \(alto\) WG mailing list" <alto.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/alto>
List-Post: <mailto:alto@ietf.org>
List-Help: <mailto:alto-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/alto>, <mailto:alto-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: alto-bounces@ietf.org
Errors-To: alto-bounces@ietf.org

In talking with the major P2P networks, I haven't heard anyone express a serious desire to degrade performance to keep people in the network (though there was some cynical joking on the topic). To explain my perspective, I co-chair the P4P Working Group, which has been doing this sort of optimization for about a year (and which hopes to work within the ALTO framework). The P4P WG participation includes many major p2p networks, including Pando, BitTorrent, Solid State, Grid Networks, LimeWire, Abacast, Azureus, Joost, etc. There's more information about some recent work at http://www.ietf.org/internet-drafts/draft-livingood-woundy-p4p-experiences-02.txt. The summary is that in exactly the scenario you assert that ALTO "does nothing" P4P (think of it as pre-ALTO) provide huge performance and efficiency benefits.

In terms of p2p application motivations, faster download speeds not only make users happier (and are thus a competitive advantage to p2p networks), but also get data distributed out into the swarm more rapidly, producing more seeds and a more resilient data availability in the mesh. Admittedly, if users get their downloads faster they might drop out of the swarm sooner, but that's an issue that (IMO) is being addressed more effectively through other mechanisms, both social and technical, rather than than degrading performance.

In terms of preferring to move data long distances rather than short distances, this doesn't make the p2p networks more resilient, because resiliences comes from interconnections that provide many data sources, not data actually moving long distances rather than short distances. While the ALTO guidance allows the p2p network to try to exchange data with closest peers preferentially, it does not prevent the p2p network from interconnecting a full global mesh to provide resilience, and I would think that they would all do so for obvious reasons.

In terms of the privacy concern that you raise, I certainly agree - I wouldn't envision using ALTO to expose any specific content and user identity to the ALTO server, because it raises privacy issues for both the P2P network and the operator of the ALTO server. The data flow that I anticipate would be one-way, with the ISP providing guidance to applications, with no information flowing the other way.

Of course, ALTO will have many applications, in some of which additional information might be extremely valuable to exchange.

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

----- Original Message -----
From: "Paul Hoffman" <paul.hoffman@vpnc.org>
To: alto@ietf.org
Sent: Friday, November 14, 2008 4:47:36 PM (GMT-0500) America/New_York
Subject: [alto] Problems with the Alto problem statement

Greetings. draft-marocco-alto-problem-statement-03 mixes two types of problem statements in a way that might confuse some readers. It covers both:

A: the problem of the large amount of P2P traffic seen on the current Internet

B: the problem of how to provide useful network information to applications

The proposed solution space for Alto will probably do nearly nothing for Problem A. Most BitTorrent traffic, which is often said to account for nearly 50% of all ISP traffic, comes from communities that would get no advantage from any of the proposed Alto solutions.

Most of the large BitTorrent communities *want* more users who are further away topologically from well-connected users, or have slower connectivity, so that the community grows. In exchange for slightly lower speed, those communities get much more stability by having torrents seeded for a longer time and more people who are willing to seed "long tail" material.

Further, any Alto solution that involves an application telling a server specific files that it is interested in, or even asking which of a list of other users would be best to communicate with, will only be useful if the user of that application is willing to directly reveal to his/her ISP what they are asking for or who they want to share with. For legitimate content, that is probably not so much of an issue. For content whose legality is questionable, it is a huge issue.

In short, an Alto might work for some scenarios, but it is pretty much irrelevant for the scenario that concerns many people now, which is the huge and growing amount of BitTorrent traffic on the net today. Therefore, any discussion of current problems with this BitTorrent traffic should be removed from the problem statements draft. Otherwise, someone reading it as part of the suite of Alto specification might think that Alto will be useful for this problem. The problems Alto might be useful for are quite different than what we have today.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
alto@ietf.org
https://www.ietf.org/mailman/listinfo/alto