[p2p-hackers] p2p in some place or other

[Serguei Osokine]

On Sunday, December 11, 2005 Michael Parker wrote:
> They use an analytical model to derive how hard to push replication
> of a key-value pair such that it can be found in a (configurable)
> constant number of hops.

	Right. But Travis is not convinced that it has to be done in
the first place, so I would imagine that the optimal nature of such
replication would be of secondary importance to him :-)

> It assumes that the data set has a zipf-like distribution.

	This makes me a bit uneasy about this model, by the way. Even
if the content distribution in P2P nets would be Zipf (and it isn't),
still I would be reluctant to implement anything that rigidly relies
on any predetermined distribution. Real functioning systems tend to
have some sort of a feedback loop and adapt to the changing situation.
In this case, it should cache the proper amount of content regardless
of how exactly it is distributed.

	But I just scanned the paper. Maybe I missed the adaptive part.

	Best wishes -
	S.Osokine.
	11 Dec 2005.

-----Original Message-----
From: p2p-hackers-bounces at zgp.org [mailto:p2p-hackers-bounces at zgp.org]On
Behalf Of Michael Parker
Sent: Sunday, December 11, 2005 8:23 PM
To: Peer-to-peer development.; Travis Kalanick
Cc: 'Peer-to-peer development.'
Subject: RE: [p2p-hackers] p2p in some place or other


Hmmm,

Emin Sirer was on this list talking about Beehive [1] not too long ago.
I read the paper, from NSDI 04, and it seems to fit your description
very well. They use an analytical model to derive how hard to push
replication of a key-value pair such that it can be found in a
(configurable) constant number of hops. It assumes that the data set
has a zipf-like distribution.

You could also try to borrow ideas from something like Glacier [2],
from NSDI 05, which replicates to maintain high fault-tolerance, and
try to exploit the replication for performance gains instead. (From
what I can remember, data-survivability is the first priority of
Glacier, not performance... As implied by the name.)

Just my two cents.

- Mike

[1] http://www.cs.cornell.edu/People/egs/papers/beehive.pdf
[2] http://www.cs.rice.edu/~druschel/publications/Glacier-NSDI.pdf


Quoting Travis Kalanick <travis at redswoosh.net>:

> One of the more interesting topics that came up from our
sushi-get-together
> was a fairly rigorous discussion about the merits (or lack thereof) of
> Proactive Caching.
>
> Let's define Proactive Caching as a mechanism where a P2P network sends
> content to a user's machine for the sole purpose of improving network
> performance and availability.  For instance, imagine that a given network
> proactively caches "long tail" content to improve availability, or
> alternatively, proactively caches content during a sudden surge of demand
> for a particular file.
>
> Deep in this discussion at the dinner (this took place in the hours after
> most folks left) was Sergei, David Barrett, myself, and others, and I
> thought it would be good to bring this topic to the list.
>
> So far, in my opinion, proactive caching on open p2p networks would
provide
> little temporal benefit in availability and performance, given the
inherent
> costs of such a scheme, and given the availability of high-performance,
> high-reliability p2p architectures.
>
> Travis
>
_______________________________________________
p2p-hackers mailing list
p2p-hackers at zgp.org
http://zgp.org/mailman/listinfo/p2p-hackers
_______________________________________________
Here is a web page listing P2P Conferences:
http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences