Proportional Quota in REsource LOcation And Discovery (RELOAD)Stonyfishmarc@stonyfish.comjdrosen.netMonmouthNJUSjdrosen@jdrosen.nethttp://www.jdrosen.netCisco170 West Tasman DriveSan JoseCA95134USA+1 408 421-9990fluffy@cisco.com
RAI
VIPR
This document defines an extension to RELOAD that limits the number of a specific kind element that can be stored by one RELOAD peer.
The base specification of RELOAD defines two variables to set the storage quota.
The first one is the maximum size of an element of a specific kind, the second one is the maximum number of elements of a specific kind that can be stored on a specific peer.
The combination of the two variables permits to limit the quantity of data that a peer have to store.
For kinds that are used with an access control policy that does not restrict the Resource-IDs, a different algorithm is needed to force storing nodes to behave.
This document describes a quota algorithm that limits the number of elements of a specific kind that a node can store in the overlay, independently of the Resource-ID used.
Another way to look at this quota algorithm is that an entity must provide a number of peers that is proportional to the number of elements of a specific kind that this entity wants to store.
It is important to understand that this quota works only for an overlay comprising only peers, and so with a configuration file containing a <clients-permitted> element set to false.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .
A peer responsible for storing kinds using the quota algorithm described in this document MUST maintain a count of the number of unique entries being stored per signer for each kind.
This operation does not require to add a field containing the Node-ID as the Node-ID of the signer is always available indirectly from the signature field of each element stored.
For example if a peer is storing 5 Resource-IDs and at each of those 5 there are two entries, all signed by the same Node-ID, it means this node is currently storing 10 unique entries for that Node-ID.
When performing the quota checks for an entry, the peer starts by verifying that the size of the entry is consistent.
If the entry if not for a replica, it then takes the <max-count> configuration parameter for this overlay, which measures the amount of entries of a specific kind a particular node can store when a <max-count-per>SIGNER</max-count-per> configuration parameter is also present.
That value is divided by the fraction of the overlay owned by this peer.
If the result is less than one, it is rounded up to two.
This is the maximum number of unique entries that can be stored for this signer.
If the peer is not yet storing this many entries for that Node-ID, the store is allowed.
Note that when evaluating a Store Request containing multiple entries per kind, the count of unique entries used for the evaluation is incremented after each successful check, but the count will be reset to its initial value if one of the check fails.
The algorithm does not apply to the replicas created by the topology plugin.
If another level of replication is done at the application level, the <max-count> value must be adjusted accordingly.
Note that because of imperfect distribution of Resource-IDs across the ring, new entries can be rejected even if the total count is under the limit.
It is the responsibility of the storing entity to calculate the maximum acceptable probability of rejection and to increase the number of peers accordingly.
[[Note: Add here the equation that can be used to calculate the probability of rejection, so applications using this quota mechanism can recommend a multiplier coefficient]]This document extends the overlay configuration document by defining a new element in the "urn:ietf:params:xml:ns:p2p:quota" namespace.The <max-count-per> element changes the meaning of the <max-count> variable.
The value "PEER" forces the <max-count> to be interpreted as been per storing peer, which is the default quota algorithm when this extension is not used.
The value "SIGNER" forces the <max-count> to be interpreted as been per signer, which is the algorithm defined by this document.
The Compact Relax NG Grammar for this element is:TBDThis document adds the following URN to the "XML Namespaces" class of the "IETF XML Registry":urn:ietf:params:xml:ns:p2p:quotaThanks to Hakim Mehmood and Mark Hendrickson for their explanations on the implementation of the quota algorithm.This document was written with the xml2rfc tool described in .Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
REsource LOcation And Discovery (RELOAD) Base ProtocolThis specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the kinds of data that must be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.Writing I-Ds and RFCs using XMLInvisible Worlds, Inc.660 York StreetSan FranciscoCA94110US+1 415 695 3975mrose@not.invisible.nethttp://invisible.net/
General
RFCRequest for CommentsI-DInternet-DraftXMLExtensible Markup LanguageThis memo presents a technique for using XML
(Extensible Markup Language)
as a source format for documents in the Internet-Drafts (I-Ds) and
Request for Comments (RFC) series.This section must be removed before publication as an RFC.The quota does not apply to replicas.Draft moved to VIPR WG.Nits.Changed "storing peer" to "signer" as this works also for replica peers.The default quota algorithm is per storing peer, not per Resource-ID.Changed the constants in the XML extension accordingly.Added running code considerations for reference implementation.Instead of having a StorageQuota parameter that gives the maximum number of entries, reused the max-count parameter (that is mandatory anyway) and changes its meaning.Removed the 3x multiplier to account for the application layer COPY, as it is application specific.Removed the additional 3x multiplier to compensate for imperfect distribution, and moved the responsibility to the storing nodes.
Reference Implementation (<http://debian.implementers.org/testing/source/reload.tar.gz>).
Marc Petit-Huguenin.
Implements version vipr-00.