Re: [p2pi] Charter and problem statement

[Laird Popkin <laird at pando.com>]

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 Popkin, CTO, Pando Networks
  mobile: 646/465-0570

----- Original Message -----
From: "Enrico Marocco" <enrico.marocco at telecomitalia.it>
To: "Stanislav Shalunov" <shalunov at shlang.com>
Cc: p2pi at ietf.org
Sent: Friday, July 11, 2008 10:06:30 AM (GMT-0500) America/New_York
Subject: Re: [p2pi] Charter and problem statement

Stanislav Shalunov wrote:
> The general problem of overlay routing and how to best expose
> information for it is big and hard.
> 
> The problem of caching, on the other hand, is well-defined, easily
> scoped, and easy to agree on.  Cache tracker location is a pure and
> simple engineering problem.  Routing information exposure has a
> substantial research component.
> 
> This charter does not let the possible WG solve the easy problem -- in
> fact, it does not even contain the word "cache".  Instead, it proposes
> a particular solution (oracle) for the more complicated routing
> information exposure problem, before the problem has even been scoped.

Ok, I see that the first change must be on the term "oracle". It wasn't
of course meant to push any particular solution; in our mind, "oracle"
could be any source of topology information, including the IDIPS
"sorting oracle" as well as the P4P iTracker or the Ono/Akamai redirect
server.

That said, I understand caches as "special" peers that can be
transparently handled by the peer selection service we are trying to
standardize (as suggested in S2.1.1 of the problem statement).
Alternatively, we would have to work on some sort of
application-dependent cache location mechanism, which, AFAICT, is not
what most people here want to pursue and I don't think is what you are
proposing. Can you suggest a rewording for the current charter to best
address caching issues?

Finally, the survey draft references several solutions for addressing
the topology information exposure problem, which have proved in the real
world to be beneficial to P2P applications in the first place (and some
to ISPs as well). I really don't want people to think that we are going
to invent a new one; instead, what we are proposing is just to define a
standard interface for existing and future peer selection optimization
services, in order to ease their adoption by different P2P and non-P2P
applications.

If you agree, but don't see it reflected in the charter, feel free to
propose alternative text.

-- 
Ciao,
Enrico

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