Re: [P2PSIP] [VIPR] Quotas
Marc Petit-Huguenin <petithug@acm.org> Thu, 09 June 2011 15:48 UTC
Return-Path: <petithug@acm.org>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50F9311E811B; Thu, 9 Jun 2011 08:48:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.385
X-Spam-Level:
X-Spam-Status: No, score=-102.385 tagged_above=-999 required=5 tests=[AWL=0.215, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfUbe31oPHvz; Thu, 9 Jun 2011 08:48:49 -0700 (PDT)
Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 68D9C11E811A; Thu, 9 Jun 2011 08:48:49 -0700 (PDT)
Received: from [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08] (shalmaneser.org [IPv6:2001:470:1f05:616:213:d4ff:fe04:3e08]) by implementers.org (Postfix) with ESMTPS id 21F432218B; Thu, 9 Jun 2011 17:47:52 +0200 (CEST)
Message-ID: <4DF0EB5A.5070400@acm.org>
Date: Thu, 09 Jun 2011 08:48:42 -0700
From: Marc Petit-Huguenin <petithug@acm.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110606 Iceowl/1.0b2 Icedove/3.1.10
MIME-Version: 1.0
To: Cullen Jennings <fluffy@cisco.com>
References: <4DED7F87.2090305@acm.org> <3B9C94BB-EA37-4BD3-A4CA-267FC86B4277@cisco.com>
In-Reply-To: <3B9C94BB-EA37-4BD3-A4CA-267FC86B4277@cisco.com>
X-Enigmail-Version: 1.1.2
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "vipr@ietf.org" <vipr@ietf.org>, P2PSIP Mailing List <p2psip@ietf.org>
Subject: Re: [P2PSIP] [VIPR] Quotas
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Jun 2011 15:48:50 -0000
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 06/09/2011 08:26 AM, Cullen Jennings wrote: > > I can't put my finger on why, but I get very nervous about suing downloadable scripts to enforce critical system constraints such as security and quotas. It just seems like a disaster waiting to happen. That said, I can't come up with any specific problem of why it would not work but it makes me feel very uneasy. I'll post a separate response on this, in p2psip only. > > It does seems reasonable to make this type of quota a general purpose extension to reload that could be used by things beyond vipr WG stuff. OK, so I'll split the quota algorithm in a separate draft (in the P2PSIP WG) with the same authors list. > > On Jun 6, 2011, at 7:31 PM, Marc Petit-Huguenin wrote: > > Now that version -15 of RELOAD is out, I am able to restart editing > draft-petithuguenin-vipr-reload-usage which is, as its name indicates, a RELOAD > usage for VIPR. Most of it can now be implemented with standard RELOAD, > excepted for one thing, the quota algorithm. > > The quota algorithm in VIPR is interesting because it looks like it can be > applied to other resources than the one handled by VIPR. This quota works by > using a variable that limits, at a responsible peer, the number of resources > that can be stored by one storing peer. More precisely, the number of unique > resource (of one kind) that a storing node can store in one responsible peer is > the quota value divided by the fraction of resources this peer is responsible > for (adjusted for the number of replicas and other parameters, but let's forget > this for now). The two standard quota parameters in RELOAD only limit the > absolute number and or size of the resources that can be stored. > > The ideal would be to add the VIPR quota inside the RELOAD base spec. Having > stuff in base is good because in this case any RELOAD implementation could be > used for VIPR (or any other overlay), and - in my opinion - having multiple > implementations of RELOAD inside one overlay is what will help an overlay to > survive a programmer error. > > Now I would agree that we should stop adding stuff to base, to have a chance to > see it published as an RFC one day, so perhaps an alternative idea is to do the > same thing for quotas that I did for access control policy: Use a script in the > configuration file to express the quota algorithm associated to a specific Kind-ID. > > Is there any opinions or questions or comments on this? > > Note that this email is cross posted with the VIPR working group, but please > follow up only in P2PSIP. - -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk3w61kACgkQ9RoMZyVa61cWowCgg9lHq4xRrcdch0PsW2NLmPAI 4dEAn33neMRjBy69CjoG5rD+vQBAuFul =SW6+ -----END PGP SIGNATURE-----
- [P2PSIP] Quotas Marc Petit-Huguenin
- Re: [P2PSIP] [VIPR] Quotas Cullen Jennings
- Re: [P2PSIP] [VIPR] Quotas Marc Petit-Huguenin
- Re: [P2PSIP] [VIPR] Quotas Marc Petit-Huguenin