Re: [p2pi] Charter and problem statement

[Laird Popkin <laird at pando.com>]

For this level of discussion, I agree that caches should simply be viewed as a peer in ALTO.

I would point out some differences that we'll want to discuss at some point, as I think that they'll require some mild extensions to ALTO as we've discussed it so far:
- The cache servers are never part of the ALTO client request (since the p2p network doesn't know about them) but the ALTO server needs to give out exact addresses of caches in its response, since they're peers that are unknown to the p2p network. This is different from the more abstract network locations (e.g. IP prefix, ASN) that ALTO otherwise uses (IMO, anyway) in order to protect user privacy. There isn't a privacy concern with revealing the location of an ISP-run cache server to the ISP. :-)
- Cache servers are protocol, application and perhaps even content specific, so that information needs to be (optionally) communicated in the ALTO request. For example, an ISP might operate BitTorrent and Pando caches, but not eDonkey caches, or it might operate different caches for different protocols on different hardware at different locations, or it might decide to cache some content (e.g. commercial content) but not other content (e.g. consumer generated content) that is transported using the same protocol and application.
- There might be some additional policy information that the ISP may wish to communicate. For example, an ISP that invests heavily in caching to relieve uplink congestion might want p2p apps to use the cache servers to the exclusion of peers within the network, etc. Of course, the implementation of this is up to the p2p application, but at the least the ISP should be able to communicate preferences.

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

----- Original Message -----
From: "Vijay K. Gurbani" <vkg at alcatel-lucent.com>
To: "Laird Popkin" <laird at pando.com>, "Stanislav Shalunov" <shalunov at bittorrent.com>
Cc: p2pi at ietf.org
Sent: Friday, July 11, 2008 10:53:56 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] Charter and problem statement

Laird Popkin wrote:
> IMO caches are a (rather valuable) special case of the general
> problem of finding optimal sources of data (for data that has
> multiple available sources).
> 
> To elaborate on this, once the ISP has an "oracle" that communicates
> network policies to applications, that seems like an ideal channel
> for communicating information about caches. Doing so explicitly and
> under the direction of the ISP and the support of the p2p networks
> seems much better than the techniques that those guys use now (e.g.
> multiple proprietary cache discovery protocols, or deep packet
> inspection and protocol hacking). As a p2p developer, I have to say
> that it's far more likely that we'd support a single standard cache
> location mechanism (especially if it gave all of the other benefits
> of an "oracle") than for us to test multiple proprietary cache
> discovery mechanisms on every download.

Laird, Stanislav: I think both of you are proposing that cache-
discovery be a part of ALTO.  I am trying to make a distinction
between /cache/ and /content/ in the context of our work.

In a P2P application-based overlay, the "best" peer (however
the network defines "best") is where the querying peer should
be sent to get the resource in question from.  If we stretch
this analogy a bit further, it does not matter that the resource
is mirrored (cached) at the "best" peer or it appears as
the only instance of resource on the "best peer" (i.e., it is
not cached.)  So in cases like this, I believe that sending
a querying peer to the "best" peer is immaterial of whether
or not the "best" peer is a caching-only server versus a
server providing original content.  The content is immutable.

In other applications like HTTP-based caching, it matters whether
or not a cache is hit or the origin server is hit.

If caching is deemed to be a part of the charter, how do we define
it for ALTO?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg at {alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs
_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi