One document matched: draft-petithuguenin-p2psip-proportional-quota-01.xml

<?xml version="1.0" encoding="US-ASCII"?>
<?rfc compact="yes" ?>

<?rfc strict="no" ?>

<?rfc symrefs="yes" ?>

<?rfc toc="yes" ?>

<rfc category="std" docName="draft-petithuguenin-p2psip-proportional-quota-01" ipr="noModificationTrust200902">
	<front>
		<title abbrev="Proportional Quota">Proportional Quota in REsource LOcation And Discovery (RELOAD)</title>

		<author fullname="Jonathan Rosenberg" initials="J.R." surname="Rosenberg">
			<organization>jdrosen.net</organization>
			<address>
				<postal>
					<street/>
					<city>Monmouth</city>
					<region>NJ</region>
					<country>US</country>
				</postal>

				<email>jdrosen@jdrosen.net</email>
				<uri>http://www.jdrosen.net</uri>
			</address>
		</author>

		<author fullname="Cullen Jennings" initials="C." surname="Jennings">
			<organization>Cisco</organization>

			<address>
				<postal>
					<street>170 West Tasman Drive</street>
					<city>San Jose</city>
					<region>CA</region>
					<code>95134</code>
					<country>USA</country>
				</postal>

				<phone>+1 408 421-9990</phone>
				<email>fluffy@cisco.com</email>
			</address>
		</author>

		<author fullname="Marc Petit-Huguenin" initials="M." surname="Petit-Huguenin">
			<organization>Stonyfish</organization>

			<address>
				<email>marc@stonyfish.com</email>
			</address>
		</author>

		<date day="4" month="July" year="2011"/>
		<area>RAI</area>
		<workgroup>P2PSIP</workgroup>

		<abstract>
			<t>
				This document defines an extension to <xref target="I-D.ietf-p2psip-base">RELOAD</xref> that limits the number of a specific kind element that can be stored by one RELOAD peer.
			</t>
		</abstract>
	</front>

	<middle>
		<section title="Introduction">
			<t>
				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.
			</t>

			<t>
				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.
			</t>

			<t>It is important to understand that this quota works only for an overlay comprising only peers, so with a configuration file containing a <clients-permitted> element set to false.</t>
		</section>

		<section title="Terminology">
			<t>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 <xref target="RFC2119"/>.</t>
		</section>

		<section title="Quota Algorithm">
			<t>
				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 in the signature field of each element stored.
			</t>

			<t>
				For example if a peer is storing 5 Resource-IDs and at each of those 5 there are two keys whose first 16 bytes correspond to a particular Node-ID, it means this node is currently storing 10 unique dictionary entries for that Node-ID.
			</t>

			<t>
				When performing the quota checks for an entry, the peer starts by verifying that the size of the entry is consistent.
				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 multiplied by by the number of replicas used by the topology plugin (i.e. 3 for Chord) and then 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.
			</t>

			<t>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.</t>

			<t>
				The algorithm takes in account only the duplications made by the topology plugin.
				If another level of duplication is done at the application level, the <max-count> value must be adjusted accordingly.
			</t>

			<t>
				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.
			</t>
		</section>

		<section title="Overlay Configuration Document Extension">
			<t>This document extends the overlay configuration document by defining a new element in the "urn:ietf:params:xml:ns:p2p:quota" namespace.</t>

			<t>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.
			</t>

			<t>The Compact Relax NG Grammar for this element is:</t>

			<figure>
				<artwork><![CDATA[
namespace pqt = "urn:ietf:params:xml:ns:p2p:quota"

kind-parameter &= element pqt:max-count-per { max-count-per-type }
max-count-per-type |= "PEER"
max-count-per-type |= "SIGNER"
max-count-per-type |= xsd:string # extensions

				]]></artwork>
			</figure>
		</section>
		<section title="Security Considerations">
			<t>TBD</t>
		</section>

		<section title="IANA Considerations">
			<t>This document adds the following URN to the "XML Namespaces" class of the "IETF XML Registry":</t>
			<t>urn:ietf:params:xml:ns:p2p:quota</t>
		</section>

		<section title="Acknowledgements">
			<t>This document was written with the xml2rfc tool described in <xref target="RFC2629"/>.</t>
		</section>
	</middle>

	<back>
		<references title="Normative References">
			<reference anchor="RFC2119">

<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author fullname="Scott Bradner" initials="S." surname="Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street>
</postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email>
</address>
</author>
<date month="March" year="1997"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
   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:

<list>
<t>
      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.
</t>
</list>
</t>
<t>
   Note that the force of these words is modified by the requirement
   level of the document in which they are used.
</t>
</abstract>
</front>

<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format octets="4723" target="http://www.rfc-editor.org/rfc/rfc2119.txt" type="TXT"/>
<format octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html" type="HTML"/>
<format octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml" type="XML"/>
</reference>
			<reference anchor="I-D.ietf-p2psip-base">
<front>
<title>REsource LOcation And Discovery (RELOAD) Base Protocol</title>

<author fullname="Cullen Jennings" initials="C" surname="Jennings">
    <organization/>
</author>

<author fullname="Bruce Lowekamp" initials="B" surname="Lowekamp">
    <organization/>
</author>

<author fullname="Eric Rescorla" initials="E" surname="Rescorla">
    <organization/>
</author>

<author fullname="Salman Baset" initials="S" surname="Baset">
    <organization/>
</author>

<author fullname="Henning Schulzrinne" initials="H" surname="Schulzrinne">
    <organization/>
</author>

<date day="27" month="May" year="2011"/>

<abstract>
<t>This 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.</t>
</abstract>

</front>

<seriesInfo name="Internet-Draft" value="draft-ietf-p2psip-base-15"/>
<format target="http://www.ietf.org/internet-drafts/draft-ietf-p2psip-base-15.txt" type="TXT"/>
</reference>
		</references>

		<references title="Informative References">
			<reference anchor="RFC2629">

<front>
<title>Writing I-Ds and RFCs using XML</title>
<author fullname="Marshall T. Rose" initials="M.T." surname="Rose">
<organization>Invisible Worlds, Inc.</organization>
<address>
<postal>
<street>660 York Street</street>
<city>San Francisco</city>
<region>CA</region>
<code>94110</code>
<country>US</country>
</postal>
<phone>+1 415 695 3975</phone>
<email>mrose@not.invisible.net</email>
<uri>http://invisible.net/</uri>
</address>
</author>
<date month="June" year="1999"/>
<area>General</area>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This 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.</t>
</abstract>
</front>

<seriesInfo name="RFC" value="2629"/>
<format octets="48677" target="http://www.rfc-editor.org/rfc/rfc2629.txt" type="TXT"/>
<format octets="71741" target="http://xml.resource.org/public/rfc/html/rfc2629.html" type="HTML"/>
<format octets="53481" target="http://xml.resource.org/public/rfc/xml/rfc2629.xml" type="XML"/>
</reference>
		</references>

		<section title="Release notes">
			<t>This section must be removed before publication as an RFC.</t>

			<section title="Modifications between draft-petithuguenin-p2psip-proportional-quota-01 and draft-petithuguenin-p2psip-proportional-quota-00">
				<t>
					<list style="symbols">
						<t>Changed "storing peer" to "signer" as this works also for replica peers.</t>
						<t>The default quota algorithm is per storing peer, not per Resource-ID.</t>
						<t>Changed the constants in the XML extension accordingly.</t>
						<t>Added running code considerations for reference implementation.</t>
					</list>
				</t>
			</section>
			<section title="Modifications between draft-petithuguenin-p2psip-proportional-quota-00 and draft-petithuguenin-vipr-reload-usage-00">
				<t>
					<list style="symbols">
						<t>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.</t>
						<t>Removed the 3x multiplier to account for the application layer COPY, as it is application specific.</t>
						<t>Removed the additional 3x multiplier to compensate for imperfect distribution, and moved the responsibility to the storing nodes.</t>
					</list>
				</t>
			</section>

			

			<section title="Running Code Considerations">
				<t>
					<list style="symbols">
						<t>
							Reference Implementation (<http://debian.implementers.org/testing/source/reload.tar.gz>).
							Marc Petit-Huguenin.
							Implements version -01.
						</t>
					</list>
				</t>
			</section>

			
		</section>
	</back>
</rfc>