Re: [p2pi] Content Identifiers sent to ALTO server?

["Stas Khirman" <stas at khirman.com>]

> -----Original Message-----
> From: Laird Popkin [mailto:laird at pando.com]
> Sent: Monday, July 21, 2008 7:29 AM
> To: John Leslie
> Cc: Stas Khirman; p2pi at ietf.org
> Subject: Re: Content Identifiers sent to ALTO server?
> 
> I don't think that either of the scenarios that you list is particularly
> likely for p2p swarm file downloading. I'll explain why, they outline the
> model of ALTO that seems most valuable for that application.
> 
> 1. If the client has a list of IP addresses, the list is short enough that
> it can test throughput with each of them all fairly quickly, so the value
> of ALTO is low in terms of optimizing p2p performance. This scenario makes
> sense for some other applications (e.g. finding a good network relay, or
> optimizing small swarm downloads).

[Stas Khirman] 
Peer list is not necessary short - it is rather current BitTorrent popular
trackers configurable restriction. In Gnutella you can get a few hundreds of
peers on the first lookup. In eMule, it restricted (IMHO) by 300 IPs per
server lookup ( you can request from multiple servers simultaneously). Plus,
peers can arrive via PEX and DHT.

BitTorrent specific limitation of 50-100 peers in the announce response is
configurable and easy to change. Beside, majority of BitTorrent
implementations can work without tracker at all - via DHT .

> From p2pi-bounces at ietf.org  Mon Jul 21 15:48:09 2008
Return-Path: <p2pi-bounces at ietf.org>
X-Original-To: p2pi-archive at ietf.org
Delivered-To: ietfarch-p2pi-archive at core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id A37893A69B4;
	Mon, 21 Jul 2008 15:48:09 -0700 (PDT)
X-Original-To: p2pi at core3.amsl.com
Delivered-To: p2pi at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id D00E83A69B4
	for <p2pi at core3.amsl.com>; Mon, 21 Jul 2008 15:48:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Level: 
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, 
	BAYES_00=-2.599]
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 lmMFFuQshRSW for <p2pi at core3.amsl.com>;
	Mon, 21 Jul 2008 15:48:05 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.194])
	by core3.amsl.com (Postfix) with ESMTP id 69ECD3A692E
	for <p2pi at ietf.org>; Mon, 21 Jul 2008 15:48:05 -0700 (PDT)
Received: from viceroy (natint3.juniper.net [66.129.224.36])
	by mrelay.perfora.net (node=mrus0) with ESMTP (Nemesis)
	id 0MKp8S-1KL4BN0NaU-0005h8; Mon, 21 Jul 2008 18:48:44 -0400
From: "Stas Khirman" <stas at khirman.com>
To: "'Laird Popkin'" <laird at pando.com>,
	"'John Leslie'" <john at jlc.net>
References: <137868081.30911216649763195.JavaMail.root at dkny.pando.com>
	<441209888.30961216650530155.JavaMail.root at dkny.pando.com>
Date: Mon, 21 Jul 2008 15:48:34 -0700
Message-ID: <006701c8eb83$ee205a80$a00d11ac at jnpr.net>
MIME-Version: 1.0
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Thread-Index: AcjrPiC/DY7ZXdGEQiiZu7I3gtPK3QAQNedQ
In-Reply-To: <441209888.30961216650530155.JavaMail.root at dkny.pando.com>
X-Provags-ID: V01U2FsdGVkX1+M0ti7sSKWveRzs2qMrx50S5I6WJC6vvrgtBd
	HUtAoRXpDN0AeL4bLM5AvZpA9eU1QqL25Bx0/cuVA8pHS2roRD
	g/HOasTVtQNKggmVNcgJA==
Cc: p2pi at ietf.org
Subject: Re: [p2pi] Content Identifiers sent to ALTO server?
X-BeenThere: p2pi at 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 at ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/p2pi>
List-Post: <mailto:p2pi at ietf.org>
List-Help: <mailto:p2pi-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2pi>,
	<mailto:p2pi-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: p2pi-bounces at ietf.org
Errors-To: p2pi-bounces at ietf.org

> -----Original Message-----
> From: Laird Popkin [mailto:laird at pando.com]
> Sent: Monday, July 21, 2008 7:29 AM
> To: John Leslie
> Cc: Stas Khirman; p2pi at ietf.org
> Subject: Re: Content Identifiers sent to ALTO server?
> 
> I don't think that either of the scenarios that you list is particularly
> likely for p2p swarm file downloading. I'll explain why, they outline the
> model of ALTO that seems most valuable for that application.
> 
> 1. If the client has a list of IP addresses, the list is short enough that
> it can test throughput with each of them all fairly quickly, so the value
> of ALTO is low in terms of optimizing p2p performance. This scenario makes
> sense for some other applications (e.g. finding a good network relay, or
> optimizing small swarm downloads).

[Stas Khirman] 
Peer list is not necessary short - it is rather current BitTorrent popular
trackers configurable restriction. In Gnutella you can get a few hundreds of
peers on the first lookup. In eMule, it restricted (IMHO) by 300 IPs per
server lookup ( you can request from multiple servers simultaneously). Plus,
peers can arrive via PEX and DHT.

BitTorrent specific limitation of 50-100 peers in the announce response is
configurable and easy to change. Beside, majority of BitTorrent
implementations can work without tracker at all - via DHT .

> 
> 2) I 
> 2) I think that it's safe to assume that p2p networks will never send a
> list of all IP addresses associated with a particular content swarm to an
> ISP's ALTO server. This raises obvious business, privacy and legal issues,
> which are at best quite concerning.

[Stas Khirman] 
If peer list is NOT associated with specific content, I see no reasons for
business, privacy and legal concerns. Please elaborate if I wrong. 

> 
> In addition, putting the ALTO protocol in the middle of a peer request
> creates unacceptable operational problems for the p2p network that would
> be far worse than any optimization that ALTO could provide. Let's compare
> a standard BitTorrent "tracker announce", a tracker announce with ALTO IP
> lookup" and "tracker announce with ALTO guidance" for a peer in a swarm of
> 10,000 peers.
> 

[Stas Khirman] 
If I understand correctly, you are describing P4P architecture where tracker
cooperates with ISPs. It is certainly preferable model for P2P CDN where
content distributed by the same entity that operate tracker (or associated
third-party). This model also assumes that beside tracker, peer client has
no other independent ways to discover new peers (like DHT and PEX) 

However, I don't see how this architecture may work in "open P2P"
applications, which generate majority of traffic today. 

The main reasons are:
- some P2Ps have no tracker at all - see Gnutella, Ares and other
- All modern P2P clients able to discover new peers without direct tracker
involvement.
- Majority of popular open trackers operated by entities that will not
cooperate with ISPs (see ThePirateBay)
- Considering BitTorrent, there are only a few major application vendors who
will probably cooperate with ALTO. Number of deployed trackers
implementations and deployments - in 100s. It will take a lot of time until
tracker owners cooperate with ALTO ( if ever)

Probably, ALTO has to consider ( but not limit to) two major architectural
models:
- cooperative tracker (P4P architecture)
- cooperative client  ("oracle" architecture)




> standard: peer announces, Tracker responds from list in memory (one MTU
> each way, UDP). Fast, reliable in-memory operation.
> 
> ALTO IP list: In this model, information sent into or out of ALTO is lists
> of IP addresses. Peer announces. Tracker sends request, with the peer
> address and a complete list of the 10,000 peers in the swarm, to the ALTO
> server. ALTO server computes optimal list and returns 50 peers. Tracker
> returns list to peer. Tracker does this (send swarm peer list, receive
> ALTO peer list) 2,000 times per second. This makes the p2p tracker slow
> and unreliable (by adding external communication to what is now an in-
> memory operation), and places a huge operational burden on the ISP's ALTO
> server. I suspect that ISPs would have problems with this as well, because
> it would effectly make their ALTO server a p2p tracker, with all that
> implies.
> 
> ALTO guidance: Tracker (updated periodically, asynchronously) receives
> optimization rules from the ALTO server. Peer announces. Tracker picks
> optimal list from known swarm peers based on the ISP's rules, and returns
> 50 peers to announcing peer. This is slightly slower than a standard
> announce, but it's all in memory in the Tracker, and only imposes a low
> volume of ALTO communications. Communication is the same as the first case
> (one MTU each way, UDP), plus one ALTO message every hour (or day, etc.)
> to update the optimization rules.
> 
> - Laird Popkin, CTO, Pando Networks
>   mobile: 646/465-0570
> 
> ----- Original Message -----
> From: "John Leslie" <john at jlc.net>
> To: "Laird Popkin" <laird at pando.com>
> Cc: "Stas Khirman" <stas at khirman.com>, p2pi at ietf.org
> Sent: Saturday, July 19, 2008 10:32:40 AM (GMT-0500) America/New_York
> Subject: Content Identifiers sent to ALTO server?
> 
> Laird Popkin <laird at pando.com> wrote:
> >
> > Note that content optimization can also (potentially) be
> > content-specific. For example, in P4P, the guidance to the p2p
> > networks can be 'tuned' to reflect the specific distributiothink that it's safe to assume that p2p networks will never send a
> list of all IP addresses associated with a particular content swarm to an
> ISP's ALTO server. This raises obvious business, privacy and legal issues,
> which are at best quite concerning.

[Stas Khirman] 
If peer list is NOT associated with specific content, I see no reasons for
business, privacy and legal concerns. Please elaborate if I wrong. 

> 
> In addition, putting the ALTO protocol in the middle of a peer request
> creates unacceptable operational problems for the p2p network that would
> be far worse than any optimization that ALTO could provide. Let's compare
> a standard BitTorrent "tracker announce", a tracker announce with ALTO IP
> lookup" and "tracker announce with ALTO guidance" for a peer in a swarm of
> 10,000 peers.
> 

[Stas Khirman] 
If I understand correctly, you are describing P4P architecture where tracker
cooperates with ISPs. It is certainly preferable model for P2P CDN where
content distributed by the same entity that operate tracker (or associated
third-party). This model also assumes that beside tracker, peer client has
no other independent ways to discover new peers (like DHT and PEX) 

However, I don't see how this architecture may work in "open P2P"
applications, which generate majority of traffic today. 

The main reasons are:
- some P2Ps have no tracker at all - see Gnutella, Ares and other
- All modern P2P clients able to discover new peers without direct tracker
involvement.
- Majority of popular open trackers operated by entities that will not
cooperate with ISPs (see ThePirateBay)
- Considering BitTorrent, there are only a few major application vendors who
will probably cooperate with ALTO. Number of deployed trackers
implementations and deployments - in 100s. It will take a lot of time until
tracker owners cooperate with ALTO ( if ever)

Probably, ALTO has to consider ( but not limit to) two major architectural
models:
- cooperative tracker (P4P architecture)
- cooperative client  ("oracle" architecture)




> standard: peer announces, Tracker responds from list in memory (one MTU
> each way, UDP). Fast, reliable in-memory operation.
> 
> ALTO IP list: In this model, information sent into or out of ALTO is lists
> of IP addresses. Peer announces. Tracker sends request, with the peer
> address and a complete list of the 10,000 peers in the swarm, to the ALTO
> server. ALTO server computes optimal list and returns 50 peers. Tracker
> returns list to peer. Tracker does this (send swarm peer list, receive
> ALTO peer list) 2,000 times per second. This makes the p2p tracker slow
> and unreliable (by adding external communication to what is now an in-
> memory operation), and places a huge operational burden on the ISP's ALTO
> server. I suspect that ISPs would have problems with this as well, because
> it would effectly make their ALTO server a p2p tracker, with all that
> implies.
> 
> ALTO guidance: Tracker (updated periodically, asynchronously) receives
> optimization rules from the ALTO server. Peer announces. Tracker picks
> optimal list from known swarm peers based on the ISP's rules, and returns
> 50 peers to announcing peer. This is slightly slower than a standard
> announce, but it's all in memory in the Tracker, and only imposes a low
> volume of ALTO communications. Communication is the same as the first case
> (one MTU each way, UDP), plus one ALTO message every hour (or day, etc.)
> to update the optimization rules.
> 
> - Laird Popkin, CTO, Pando Networks
>   mobile: 646/465-0570
> 
> ----- Original Message -----
> From: "John Leslie" <john at jlc.net>
> To: "Laird Popkin" <laird at pando.com>
> Cc: "Stas Khirman" <stas at khirman.com>, p2pi at ietf.org
> Sent: Saturday, July 19, 2008 10:32:40 AM (GMT-0500) America/New_York
> Subject: Content Identifiers sent to ALTO server?
> 
> Laird Popkin <laird at pando.com> wrote:
> >
> > Note that content optimization can also (potentially) be
> > content-specific. For example, in P4P, the guidance to the p2p
> > networks can be 'tuned' to reflect the specific distribution of
> >n of
> > content.
> 
>    This is (potentially) helpful when content is sufficiently static
> to flood the distribution information to all ALTO servers. This is
> not the general case, and might not even be the most common case in
> future scenarios.
> 
> > Perhaps the way to phrase this is that the ALTO server MUST support
> > operation with no content identifiers, but ALTO clients MAY send
> > content identifiers?
> 
>    I think Stas was saying that even receiving and discarding content
> Identifiers could cause undesirable legal exposure to large ISPs.
> In any case, I agree it could.
> 
>    I see two very different use cases for what we're discussing here.
> 
> 1. Client has a list of IP addresses, and wants to know which to
>    try first;
> 
> 2. Client doesn't have a list of IP addresses, but has a Content
>    Identifier, and wants an ordered list of IP addresses to try.
> 
>    I frankly would much prefer to develop these separately. The
> second might well have reason to call upon the first; but the first
> never has any reason to make use of the second. Trying to combine
> both into a single protocol complicates things unnecessarily (even
> before the legal complications come into play).
> 
>    Also, the two cases deal in information best known by parties
> with vastly different interests in limiting distribution of that
> information -- up to and including a business decision to obscure
> or even falsify the information passed to certain other parties.
> 
>    The technical problems of combining both into a single protocol
> look easy enough, but yield no measurable benefit. The legal and
> information-protection problem are much more serious.
> 
> --
> John Leslie <john at jlc.net>

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


 content.
> 
>    This is (potentially) helpful when content is sufficiently static
> to flood the distribution information to all ALTO servers. This is
> not the general case, and might not even be the most common case in
> future scenarios.
> 
> > Perhaps the way to phrase this is that the ALTO server MUST support
> > operation with no content identifiers, but ALTO clients MAY send
> > content identifiers?
> 
>    I think Stas was saying that even receiving and discarding content
> Identifiers could cause undesirable legal exposure to large ISPs.
> In any case, I agree it could.
> 
>    I see two very different use cases for what we're discussing here.
> 
> 1. Client has a list of IP addresses, and wants to know which to
>    try first;
> 
> 2. Client doesn't have a list of IP addresses, but has a Content
>    Identifier, and wants an ordered list of IP addresses to try.
> 
>    I frankly would much prefer to develop these separately. The
> second might well have reason to call upon the first; but the first
> never has any reason to make use of the second. Trying to combine
> both into a single protocol complicates things unnecessarily (even
> before the legal complications come into play).
> 
>    Also, the two cases deal in information best known by parties
> with vastly different interests in limiting distribution of that
> information -- up to and including a business decision to obscure
> or even falsify the information passed to certain other parties.
> 
>    The technical problems of combining both into a single protocol
> look easy enough, but yield no measurable benefit. The legal and
> information-protection problem are much more serious.
> 
> --
> John Leslie <john at jlc.net>

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