Re: [VIPR] Quotas

[Marc Petit-Huguenin <[e-mail]>]

-----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: [e-mail]
Professional email: [e-mail]
Blog: http://blog.marc.petit-huguenin.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk3w61kACgkQ9RoMZyVa61cWowCgg9lHq4xRrcdch0PsW2NLmPAI
4dEAn33neMRjBy69CjoG5rD+vQBAuFul
=SW6+
-----END PGP SIGNATURE-----