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

[Laird Popkin <laird at pando.com>]

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