Re: [p2pi] Charter and problem statement

[Laird Popkin <laird at pando.com>]

Comments below.

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

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

Some comments inline...


On 7/11/08 8:10 AM, "Laird Popkin" <laird at pando.com> wrote:

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

After a client knows about the IP address of the cache (which in its
interpretation might be just a very good peer), it can communicate such
'peer' to others peers in the network.

As I'm sure you know both Bittorrent and emule have source exchange between
peers, so after the cat is out of the box, how to prevent such information
from being disseminated? Or do we want to prevent it?

If the idea is for peers to use caches, such information should be
disseminated, no?

LP: Yes, Pando implements peer-exchange as well. And it's probably better for cache server addresses not to be passed around. For example, if a peer in ISP A finds out about a cache server in ISP A's infrastructure, and tells a peer in ISP B about that peer, you'll have ISP B's customers using the cache server at ISP A (or at least trying to). It'd probably be better for the client to know that it's been informed of a peer operated by their ISP so that they know not to send it around to other peers, because that'll just lead to lots of failed connections (or a cache server serving off-net).

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.

I believe the front end of the cache might be protocol specific. So, emule
and Bittorrent, use different protocols divide the file, hash and serve
content, but the content is the same.

LP: Yes, some cache servers support multiple protocols over one set of content, while others are protocol specific (e.g. HTTP caches are different from eDonkey caches), or support multiple protocols, each with their own set of content. Given that we don't know how this will all play out over time, I'd suggest giving the ISP (and ALTO server) maximum flexibility to decide what to do by having a few fields that can be used to communicate information such as application, protocol, etc., and let the ALTO server implementors figure out what to do with them based on ISP requirements. :-)

Of course there might be policies involved in commercial vs. user generated
content as you point out.

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

Agreed, but does not seem to within the scope of ALTO. It would probably be
within proprietary extensions.

LP: As long as it's extensible (which ALTO will be) that's fine. Though hopefully really basic concepts like this can be negotiated as "open" rather than "proprietary" extensions.

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


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