[p2p-hackers] p2p in some place or other

[Serguei Osokine]

On Sunday, December 11, 2005 Travis Kalanick wrote:
> 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.

	...and I was on the other side of this debate.

	My point was that most of content in open P2P networks is
trapped in the long tail; see, for example:

[1] http://p2pecon.berkeley.edu/pub/CWC-EC05.pdf

and

[2] http://www.mpi-sws.mpg.de/~gummadi/papers/p118-gummadi.pdf

- the number of copies of the average file is truly pathetic. As a
result, the average download experience is slow and unreliable. For
example, the study [2] suggests than in 2002 as many as two thirds of
"transactions" (HTTP requests for a single data chunk) used to fail 
in Kazaa. [Presumably due to the source host overload - Oso]

	This situation is widely replicated all over P2P space, being
observed in some form in Kazaa, Gnutella, eDonkey, etc. The overload
of the uploaders was discussd in Gnutella for almost as long as I can
remember.

	The suggested countermeasures include download queues, try-later
responses and such, but they all have one thing in common: they suck.
The user experience stays pathetic, as can be attested by anyone trying
to hunt down something other than a popular file. 

	And the reason for this is quite understandable - if most of 
the content exists in just one or two copies, what good are the swarm
downloaders and other marvelous instruments of progress? This single
copy that you need might be on a single host behind the modem in
Albania, the host might go off-line at any moment, and to make it 
more fun, it might be trying to upload five other files (different
files, mind you) to five other people at the same time. 

	What is important here is that the de facto statistical
distribution of content on the open P2P nets shown in [1] and [2]
tells us that this is happening not just for something that we tend
to dismiss as "rare files". No - these files represent a huge share
of the network content, and as much as 50-70% of the user download
attempts are for these "rare files". And all this experience sucks,
no matter what fancy download queues are introduced into the system.
Simply because there's not enough uplink bandwidth and content
sources.

	So I'm not saying that proactive caching is easy to implement,
does not require any resources, or even that it will will work well
in practice. I'm just saying that without it the user experience will
continue to suck, and proactive caching is the single mechanism that
I can see which is potentially able to fix this situation. Unless
this rare file is proactively replicated to 5-10 other nodes, I do
not see how the adequate download speeds can be achieved.

	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 Travis Kalanick
Sent: Sunday, December 11, 2005 6:35 PM
To: 'Peer-to-peer development.'
Subject: RE: [p2p-hackers] p2p in some place or other


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

-----Original Message-----
From: p2p-hackers-bounces at zgp.org [mailto:p2p-hackers-bounces at zgp.org] On
Behalf Of Wolfgang Mueller
Sent: Saturday, December 10, 2005 7:15 AM
To: Peer-to-peer development.
Subject: Re: [p2p-hackers] p2p in some place or other

Dear SF peers,

Would it be possible to spice these reports up by 
publishing not only a writeup of the menu but also 
of your topics? BTW I am munching typically 
German Christmas cookies here... And don't denigrate 
places that enjoy a winter recognizable as such :-D . 

And: imagine a Bavarian beer-to-beer meeting. People here confuse b,p,d
and t, anyway, so let's use this ambiguity :-D

Cheers,
Wolfgang

--
Dr. Wolfgang Mueller
LS Medieninformatik
Universitaet Bamberg
_______________________________________________
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


_______________________________________________
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