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

From: Laird Popkin <[email-masked]>
Date: Mon, 21 Jul 2008 10:28:50 -0400 (EDT)

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).

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.

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.

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" <[email-masked]>
To: "Laird Popkin" <[email-masked]>
Cc: "Stas Khirman" <[email-masked]>, [email-masked]
Sent: Saturday, July 19, 2008 10:32:40 AM (GMT-0500) America/New_York
Subject: Content Identifiers sent to ALTO server?

Laird Popkin <[email-masked]> 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
> 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 <[email-masked]>
_______________________________________________
p2pi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/p2pi

---

From: "Woundy, Richard" <[email-masked]>
Date: Mon, 21 Jul 2008 17:53:44 -0400

>ALTO guidance: Tracker (updated periodically, asynchronously) receives
optimization rules from the ALTO server.

Just to make sure I understand: in this scenario, the tracker would be
the ALTO client. The ALTO client (tracker) could send ALTO requests with
content IDs, and ALTO servers could respond with P2P caching servers
that store that content. When peers request content from the tracker,
the tracker can refer the peer to specific P2P caching servers, without
additional ALTO requests. The ALTO server would be insulated from any
peer's request for that content.

-- Rich

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Laird Popkin
Sent: Monday, July 21, 2008 10:29 AM
To: John Leslie
Cc: [email-masked]
Subject: Re: [p2pi] 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).

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.

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.

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.

---

From: Laird Popkin <[email-masked]>
Date: Mon, 21 Jul 2008 18:02:16 -0400 (EDT)

Yes, exactly. That's the case (IMO) for both normal peers and p2p caches.

----- Original Message -----
From: "Richard Woundy" <[email-masked]>
To: "Laird Popkin" <[email-masked]>, "John Leslie" <[email-masked]>
Cc: [email-masked]
Sent: Monday, July 21, 2008 5:53:44 PM (GMT-0500) America/New_York
Subject: RE: [p2pi] Content Identifiers sent to ALTO server?

-- Rich

---

From: John Leslie <[email-masked]>
Date: Mon, 21 Jul 2008 18:33:20 -0400

Laird Popkin <[email-masked]> wrote:
> likely for p2p swarm file downloading.

   I'm perfectly happy for "client" to mean the tracker itself, BTW.

> I'll explain why, they outline the model of ALTO that seems most
> valuable for that application.
> 
>    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.

   There's no functional problem with such a list exceeding 100 IPs.
Many ISPs consider 100 simultaneous TCP connections abusive. (Unless
they actually overlap, I don't see how they can be tried "quickly".)

> This scenario makes sense for some other applications (e.g. finding
> a good network relay, or optimizing small swarm downloads).

   Exactly. We should not design something useful only for p2p swarm.

> 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.

   Nonetheless, privacy is compromised as soon as they send it to a
potential user. More likely, they would send an incomplete list,
possibly adding non-swarm IPs to obscure things.

> creates unacceptable operational problems for the p2p network that
> would be far worse than any optimization that ALTO could provide.

   I don't follow you. I see neither "unacceptable operational problems"
nor a lack of potential optimization to outweigh them.

> 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.

   Please do...

> standard: peer announces, Tracker responds from list in memory (one
> MTU each way, UDP). Fast, reliable in-memory operation.

   One Round-Trip-Time; but client must try the IPs in turn. Often it
will go through several TCP connections on paths the ISP would prefer
weren't used.

> 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.

   I doubt they'd send all 10,000, but if they did we're talking no
more than tens of milliseconds, still all from memory.

> ALTO server computes optimal list and returns 50 peers.

   50 seems enough for an end-user to actually try.

> receive ALTO peer list) 2,000 times per second.

   I _really_ doubt they'd send 10,000 IPs 2,000 times a second; but
that's for them to optimize. (An obvious optimization is to determine
the AS number of the end-user.)

> This makes the p2p tracker slow and unreliable (by adding external
> communication to what is now an in-memory operation),

   Any tracker that busy would no doubt cache the information useful
for ordering the list, and serve from cache rather than wait for a
response from the ALTO server if a similar IP pairing hadn't expired
from the cache.

> and places a huge operational burden on the ISP's ALTO server.

   ISPs _could_ manage such a load, but certainly would not choose to
do so unless they saw a return on the investment.

> 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.

   I don't follow...

> optimization rules from the ALTO server.

   Certainly a reasonable design.

> Peer announces.

   I don't follow...

> 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.

   The devil is in the details...

   Obviously, there could be a simple rule, in the nature of always
prefer ASs in this order. But that won't cover all situations, and
risks causing the whole service to be ignored.

   A more useful rule would state that certain CIDR blocks can reach
other CIDR blocks over a path with these characteristics. While this
implies some computation on the part of the Tracker making the query,
that can easily be cached by CIDR-block-pairs.

   So, you have made I case for returning CIDR length on ALTO replies.
I agree that looks like a good idea.

   I didn't mention cacheing, because it seemed a local optimization.
I still don't think it _needs_ to be in the spec, but it very likely
deserves to be mentioned.

   (And please don't forget that ALTO will be used for more than just
p2p swarms.)

---

From: "Stas Khirman" <[email-masked]>
Date: Mon, 21 Jul 2008 15:48:34 -0700

> From: Laird Popkin [mailto:[email-masked]]
> Sent: Monday, July 21, 2008 7:29 AM
> To: John Leslie
> Cc: Stas Khirman; [email-masked]
> Subject: Re: Content Identifiers sent to ALTO server?
> 
> 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 .

> 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. 

> 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)

> 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
> 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.
>