> -----Original Message----- > From: Eric Rescorla [mailto:[EMAIL PROTECTED] > Sent: Friday, November 14, 2008 7:24 PM > To: Narayanan, Vidya > Cc: [email protected] > Subject: Re: [P2PSIP] Should RELOAD impose a size restriction > for storage? > > At Fri, 14 Nov 2008 01:04:28 -0800, > Narayanan, Vidya wrote: > > > > > > When an overlay is composed of heterogeneous nodes, it is > unrealistic > > to expect all nodes to have the ability to store and serve all data > > That's what being a node means in this context. If you can't > meet the minimum requirements you shouldn't join the overlay > as a peer, but rather as a client. >
It is the minimum requirement I was talking about. I agree that all peers must support the minimum requirement. Turns out I didn't read the draft carefully enough - it looks like the size is part of the overlay configuration. Sorry for missing that. However, I don't see an error code for rejecting a store request due to its size - it may help to have one. > > > Now, a node may always reject the request to store something. > > In a structured overlay, the particular set of nodes which > are responsible for storing a given data object is defined by > the topology. If nodes unilaterally refuse to store given > kinds of data, this basically breaks the underlying semantics > of the overlay, with the problem made worse by the fact that > the overlay topology shifts over time. > What I was getting at above was that there is no way to enforce compliance to the overlay requirements in a distributed system. I wasn't saying that a compliant peer would unilaterally refuse a conforming store request. > > > It is not readily possible for a storing node to tell what type of > > data it is being requested to store > > On the contrary: in RELOAD data is typed by "usage", so it is > fairly clear. > I think there is more to discuss on this topic. I'll take this up in a separate thread. > > > - however, it may be reasonable > > for overlays to have a guidance on the upper bound on the size of a > > single data item. This should be configurable for overlays and may > > even be advertised as part of the overlay configuration. > This allows > > participating nodes to be composed of heterogeneous > capabilities and > > still maintain a reasonable level of robustness in the > overlay. Nodes > > may choose to accept data items larger than this upper bound - > > however, the data owner must be prepared for a rejection of > the store > > request when the data is larger than the bound. > > > > Thoughts? > > We considered exactly this design during the early design > phase of RELOAD. Unfortunately, it's unstable. The problem is > that the set of nodes assigned to store a data value shifts over time. > So, I may store value X with node A, which can accept it, but > then node B takes over some of node A's space and node B > can't store the data and it just silently vanishes. In order > to provide any reasonable level of service expectation, the > nodes have to be willing to provide more or less the same > level of service as far as storage goes. > I think we agree on this - my concern was coming from incorrectly thinking that there is no size requirement specified for an overlay. Designing an overlay where nodes may have variable bounds doesn't make sense and I wasn't suggesting we go there. Vidya _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
