[p2p-hackers] p2p in some place or other

[Serguei Osokine]

On Sunday, December 11, 2005 David Barrett wrote:
> Thus the uploader can either choose to:
> a) Send the file only to the downloader
> b) Only to the innocent bystander
> c) To both

	Add to this:

d) send the file to bystander in advance, even before the downloader
   asks for it

- and then you'll cover pretty much every possible case of proactive
caching, because

e) send the file to both bystander and downloader in advance

is essentially just an extreme case of "d" :-)

	Note that Dijjer, for example, seems to use more or less "c" -
but I'm not sure if its usage model can be squeezed to fit into your
simplified scenario. In real life there might be subsequent requests
for the cached file, but since you're saying that the bystander won't
ever need the file, there's no one to generate such requests in your
model. So even if Dijjer benefits from its caching, your model will
miss it.

	Best wishes -
	S.Osokine.
	11 Dec 2005.


-----Original Message-----
From: David Barrett [mailto:dbarrett at quinthar.com]
Sent: Sunday, December 11, 2005 7:48 PM
To: osokin at osokin.com; Peer-to-peer development.
Subject: Re: [p2p-hackers] p2p in some place or other


Serguei Osokine wrote:
> 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.

... and I'm somewhere in between.

I suspect proactive caching is useful for some configurations of files,
uploaders, and would-be-downloaders, but I'm not sure if that
configuration exists in the real world to such a degree that it's worth
worrying about.  Furthermore, I suspect the "real world" in all its
glory is far too complicated to get agreement upon quickly, so I think
we should first start with simplified worlds and then work up to the
real one.

For starters, assume "the network" consists of:
1) A single "uploader" with exactly one file
2) A "downloader" that wants the file (but doesn't have it)
3) An "innocent bystander" that neither has nor wants the file

(Further assume that there will never be any more files, more nodes, and
the innocent bystander will never want the file.  Also, assume all three
nodes have identical, equal upload/download speeds, unlimited storage,
and have been and will be online for eternity.)

Thus the uploader can either choose to:
a) Send the file only to the downloader
b) Only to the innocent bystander
c) To both

I'd define "proactive caching" as options (b) and (c).  And in this
specific configuration, I don't see it as useful.  I'll define "success" as:
- Transfers the maximum number of files to those who want them
- In the shortest possible time

(Note, I'm explicitly not valuing conservation of bandwidth or storage
in order to simplify the case for proactive caching.)

Thus for this absolute most basic network, I'd say option (a) is clearly
the right choice.

Can we agree on that much?

If so, what is the *smallest* way this network must change in order for
proactive caching to begin offering value?

-david