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

From: "Michal Giermasinski" <[email-masked]>
Date: Sat, 22 Sep 2007 08:23:50 +0200

Hello Jiang!

I do agree that capacity of peers may lead us to a funcional problem with
the network.

Some company said "Network is the computer". This can be read that even if
we have a wide open network we also have some bounderies. I believe that we
can consider p2p overlay as a finite capacity. If there is no free space,
one can not place his data in it - simple!

Whe only thing that is worth to be considered is optimising the way of
storing information in the overlay. When one would like to place some data
into overlay DHT algorithm should give him the most suitable peer to do
this. If a peer has a lot of free space it should keep the biggest data
portions firstly. Such way of handling data may cause some modifications
into DHT algorithm that probably may cause some difficulties.

What is your oppinion about this.

best regards
Michal Giermasinski

2007/7/19, JiangXingFeng <[email-masked]>:
>
> 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
> >
> > On 18-Jul-07, at 11:07 , Michael Chen wrote:
> >
> > > 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.
> > >
> >
> > 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
> >
> >
> > _______________________________________________
> > P2PSIP mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/p2psip
>
>
>
> _______________________________________________
> P2PSIP mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/p2psip
>
_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: JiangXingFeng <[email-masked]>
Date: Mon, 24 Sep 2007 10:02:02 +0800

Hello Jiang!
 
>I do agree that capacity of peers may lead us to a funcional problem with
the >network.
 
>Some company said "Network is the computer". This can be read that even if
we >have a wide open network we also have some bounderies. I believe that we
can >consider p2p overlay as a finite capacity. If there is no free space,
one can not place >his data in it - simple! 

Maybe this is the simplest idea to this problem. ASP proposed by Jonathon
introduces the concept of usage and the usage determines the capacity of the
peer who will support this usage. 
 
>Whe only thing that is worth to be considered is optimising the way of
storing >information in the overlay. When one would like to place some data
into overlay DHT >algorithm should give him the most suitable peer to do
this. If a peer has a lot of free >space it should keep the biggest data
portions firstly. Such way of handling data may >cause some modifications
into DHT algorithm that probably may cause some >difficulties. 
 
Yes, I agree with you that a responsible peer for a key being short of
memory to store the data associated with the key may make the store
operation failure. If the flexible storage mechanism is introduced into the
overlay and storage operation may be like the cache, it means the location
for storing the data has no determined mapping with the key. So it is hard
for the data requester to get the data. IMHO, solving this problem at the
layer above the distributed database by the DHT layer may be wiser than
breaking the mapping between the key and the peer.  

best regards
Michal Giermasinski

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.

Would we take the data size into consideration when we design peer protocol?

Comments?
--
Jiang XingFeng

> From: Philip Matthews [mailto:[email-masked] ]

---

From: "Mosiuoa Tsietsi" <[email-masked]>
Date: Tue, 25 Sep 2007 10:37:40 +0200

Hi all,

I agree that implementing this facility at a layer above the DHT logic is a
possibility.  But I also think it can be achieved innately within the DHT
algorithms without breaking the mapping structure.  Much in the same way
that proximity metrics are incorporated into DHT algorithms (for example to
choose the "best neighbor") perhaps the same kind of logic can be used to
choose the "best storer" of data. When the DHT is performing maintenance
tasks, as it optimises routing tables and such, it can also take into
consideration some storage metrics as well.

Yes, no, maybe?

Mos

On 9/24/07, JiangXingFeng <[email-masked]> wrote:
>
> Hello Jiang!
>
> >I do agree thatcapacity of peersmay lead us to a funcional problem with
> the >network.
>

---

From: JiangXingFeng <[email-masked]>
Date: Wed, 26 Sep 2007 09:24:25 +0800

Hi all,

>possibility.  But I also think it can be achieved innately within the DHT
algorithms >without breaking the mapping structure.  Much in the same way
that proximity >metrics are incorporated into DHT algorithms (for example to
choose the "best >neighbor") perhaps the same kind of logic can be used to
choose the "best storer" of >data. When the DHT is performing maintenance
tasks, as it optimises routing tables >and such, it can also take into
consideration some storage metrics as well. 

Yes, if the DHT algorithm could provide the storage property like what
you've just described, I think it would be the best solution to the issue of
storage shortage of the peer.  P2PSIP peer protocol does not intend to
develop new DHT algorithms. What it really does is to accommodate different
DHT algorithms and make sure the message format could be extensible enough
to convey the semantics of the each DHT algorithm. So if the DHT algorithm
does not solve the shortage of the peer's storage, the better choice to this
issue is to solve it on the upper layer application above.

Comments?

Mos

---

From: "Mosiuoa Tsietsi" <[email-masked]>
Date: Wed, 26 Sep 2007 11:55:09 +0200

Hi again,

True, it's not the aim of P2P SIP to engineer DHT algorithms, but to reuse
what is there and hopefully provide generic interfaces to all things DHT (or
all things P2P for that matter).  But I am hoping that pressure for such
features will stimulate work in the area to provide such tweaks in the
algorithms.  Much like you said Jiang, until such a time, the P2P node
probably needs to be intelligent enough to at the higher level to avoid
irregularities in the DHT.

In the case of P2P over SIP, a node would probably want to send out
something like a 480 Temp Unavailable or 486 Busy Here, and indicate to the
requestor to try some other node closer to the key until one such node is
found. I'm guessing if there is no proper candidate found (though I imagine
it is quite unlikely that such a situation may arise), the node is not
allowed to register, until some free space is found in the DHT.

More or less the same for SIP over P2P, where the associated protocols
employed for the put operation would fail, and the node would not be allowed
entry until later.

That said, the stuff I have been working on explores the possibility of
creating a new niche market for application developers who develop plugin
wrapper objects for currently existing DHT implementations which implement a
generic interface.  It does require a rather detailed understanding of the
inner working of the DHT itself.  I'm hoping that other work in the area
will put such kind of pressure so that more people start work in
interventions in DHTs for specific use in applications such as P2P SIP.

Mos

---

From: "Michal Giermasinski" <[email-masked]>
Date: Thu, 27 Sep 2007 10:55:28 +0200

Hello Mosiuia, Jiang,

I can see a potential problem here. When for storing some data in a peer
that has not enough place to store it you opt to send SIP 480 or 486. Then
data can be stored in the relevant peer with key neer the chosen one. For
sure this will work. But there will be a problem when peer C would like to
read these data. He will try to retrieve some information according to the
known key for DHT. But when reaching the node that was supposed to store
information this will fail. 3xx message (redirection) will be sent.

THis will work but we need to remember that this will not be optimal I
guess.

kind regards
Michal

---

From: Spencer Dawkins <[email-masked]>
Date: Thu, 27 Sep 2007 08:00:53 -0500

Does the "not enough storage" peer remember specific key/value pairs that have been stored on an alternative peer, or just 3XX everything it doesn't find locally to the same alternative peer?

Spencer
  ----- Original Message ----- 
  From: Michal Giermasinski 
  To: Mosiuoa Tsietsi 
  Cc: P2PSIP Mailing List 
  Sent: Thursday, September 27, 2007 3:55 AM
  Subject: Re: [P2PSIP] A DHT question on peers running out of storage

  Hello Mosiuia, Jiang,

  I can see a potential problem here. When for storing some data in a peer that has not enough place to store it you opt to send SIP 480 or 486. Then data can be stored in the relevant peer with key neer the chosen one. For sure this will work. But there will be a problem when peer C would like to read these data. He will try to retrieve some information according to the known key for DHT. But when reaching the node that was supposed to store information this will fail. 3xx message (redirection) will be sent. 

  THis will work but we need to remember that this will not be optimal I guess.

  kind regards
  Michal

    True, it's not the aim of P2P SIP to engineer DHT algorithms, but to reuse what is there and hopefully provide generic interfaces to all things DHT (or all things P2P for that matter).  But I am hoping that pressure for such features will stimulate work in the area to provide such tweaks in the algorithms.  Much like you said Jiang, until such a time, the P2P node probably needs to be intelligent enough to at the higher level to avoid irregularities in the DHT.  

    In the case of P2P over SIP, a node would probably want to send out something like a 480 Temp Unavailable or 486 Busy Here, and indicate to the requestor to try some other node closer to the key until one such node is found. I'm guessing if there is no proper candidate found (though I imagine it is quite unlikely that such a situation may arise), the node is not allowed to register, until some free space is found in the DHT. 

    More or less the same for SIP over P2P, where the associated protocols employed for the put operation would fail, and the node would not be allowed entry until later.

    That said, the stuff I have been working on explores the possibility of creating a new niche market for application developers who develop plugin wrapper objects for currently existing DHT implementations which implement a generic interface.  It does require a rather detailed understanding of the inner working of the DHT itself.  I'm hoping that other work in the area will put such kind of pressure so that more people start work in interventions in DHTs for specific use in applications such as P2P SIP. 

    Mos 

    On 9/26/07, JiangXingFeng <[email-masked] > wrote: 
      Hi all,

      Comments?

      Mos

------------------------------------------------------------------------------

---

From: "Mosiuoa Tsietsi" <[email-masked]>
Date: Thu, 27 Sep 2007 17:46:56 +0200

Hi again,

If we assume that the overlay refuses to store the key because the correct
root of the key is unable to  hold it due to exhausted storage capacity,
then we find ourselves in a similar situation that skype did.

However, if we allow the root of the key to delegate the key to another
adjacent node, it probably must maintain state about that (some pointer that
is lighter than storing the actual resource), otherwise, how do we
differentiate between a key that doesn't exist in the overlay anymore (i.e.
a node that has since resigned and had its binding removed from the overlay)
and a key that is on the adjacent node? Otherwise, we find ourselves 3XX'ing
for stuff that's not there anymore.

Taking a step back though, I think it's unlikely to happen.  If the only
nodes that store keys are the peer nodes then I think constraints are put on
them to have enough storage to implement the location service.

My thots,

Mos

On 9/27/07, Spencer Dawkins <[email-masked]> wrote:
>
>  Does the "not enough storage" peer remember specific key/value pairs that
> have been stored on an alternative peer, or just 3XX everything it doesn't
> find locally to the same alternative peer?
>
> Spencer
>
> *From:* Michal Giermasinski <[email-masked]>
> *To:* Mosiuoa Tsietsi <[email-masked]>
> *Cc:* P2PSIP Mailing List <[email-masked]>
> *Sent:* Thursday, September 27, 2007 3:55 AM
> *Subject:* Re: [P2PSIP] A DHT question on peers running out of storage
>
> Hello Mosiuia, Jiang,
>
> > True, it's not the aim of P2P SIP to engineer DHT algorithms, but to
> > reuse what is there and hopefully provide generic interfaces to all things
> > DHT (or all things P2P for that matter).  But I am hoping that pressure for
> > such features will stimulate work in the area to provide such tweaks in the
>  ------------------------------
>