Subject: [P2PSIP] A DHT question on peers running out of storage

From: Michael Chen <[email-masked]>
Date: Wed, 18 Jul 2007 07:07:20 -0800

Hi,

I have a general DHT question. Say peer X joint the overlay. When 
another peer registers a resource that should be stored in X, X runs out 
of storage space for this particular resource. What happen?

1) Should X resign from the overlay?

2) Reply resource registration failure and stay in the overlay?

3) Reply registration success but later reply "not found" when asked for 
this resource? In this case, the querying party will try the replica 
peers of this resource.

Thanks

Michael Chen
IDS Software

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Philip Matthews <[email-masked]>
Date: Wed, 18 Jul 2007 21:22:49 -0400

On 18-Jul-07, at 11:07 , Michael Chen wrote:

> another peer registers a resource that should be stored in X, X  
> runs out of storage space for this particular resource. What happen?
>
> 3) Reply registration success but later reply "not found" when  
> asked for this resource? In this case, the querying party will try  
> the replica peers of this resource.
>

For the algorithms I have seen, the assumption is that this case  
cannot happen.
In P2PSIP, we have briefly talked about this by saying: Don't try to  
store too much in the overlay.

- Philip

---

From: JiangXingFeng <[email-masked]>
Date: Thu, 19 Jul 2007 09:38:34 +0800

In P2PSIP community, the assumption is what Philip has just said. 

In some old P2P file system, for example PAST, it uses some techniques to
solve this problem in the layer above the P2P algorithm. 

One option is to store some information of small size on X, for example, the
Key, and a pointer to the data being stored. Where the data is stored is
kept in the pointers. PAST will choose another capable peer to store the
data of large size. 

A fallback option is to re-encode the resource and get a different key. So
it will be stored on a peer which has enough space. But problem in this
option is that peers who will look up this resource could not know the new
encoding about this resource exactly, so it is hard for searcher to find
this resource. 

Would we take the data size into consideration when we design peer protocol?
Or it is up to upper layer to address this issue? 

Comments? 
--
Jiang XingFeng

> -----Original Message-----
> From: Philip Matthews [mailto:[email-masked]]
> Sent: Thursday, July 19, 2007 9:23 AM
> To: Michael Chen
> Cc: P2PSIP Mailing List
> Subject: Re: [P2PSIP] A DHT question on peers running out of storage
>

---

From: Dean Willis <[email-masked]>
Date: Thu, 19 Jul 2007 14:29:46 -0500

Philip Matthews wrote:

> For the algorithms I have seen, the assumption is that this case cannot
> happen.

You, sir, are an optimist.

Having been clubbed repeatedly about the head and shoulders by Murphy's
Law and its various corrollaries I've come to believe O'Tool's
commentary: Murphy was an optimist too.

http://www.murphys-laws.com/murphy/murphy-laws.html

But seriously, I expect that as people learn that things can be stored
"in the overlay", they will be. All sorts of things, and lots of them.
Work expands to fill the allotted time, and the volume of things stored
expands to fill the available storage.

That's why I see a requirement for peers to be able to differentiate the
amount of whatever resource is used to provide whatever service, above
the absolute mininum required to be a peer, they are willing to provide.
Further, I believe that not all peers will offer all services.

This leads me to ponder a few questions:

1) What, if any, services MUST a peer provide to the overlay in order to
be a real peer and not some kind of "client"?

2) What happens when a peer (perhaps one supporting only the minimal set
of services in #1 above) gets overloaded? Does it cease to be a peer?
Does it crash? Does it break the overlay?

3) What, if any, non-required services might a peer offer?

4) If we have non-required services. how do we go about finding out
which services a peer offers, or what peers offer a given service?

5) How do we find the peer most efficiently positioned to provide a
service we're looking for? Do we even need to do this, or can we assume
all peers are equiefficient in service delivery?

6) Is there a fundamental difference between storing contact info for a
client and storing anything else?

--
Dean