Subject: [VIPR] Quotas

From: Marc Petit-Huguenin <[email-masked]>
Date: Mon, 06 Jun 2011 18:31:51 -0700

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.

Thanks.

- -- 
Marc Petit-Huguenin
Personal email: [email-masked]
Professional email: [email-masked]
Blog: http://blog.marc.petit-huguenin.org

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 9 Jun 2011 09:26:32 -0600

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. 

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. 

On Jun 6, 2011, at 7:31 PM, Marc Petit-Huguenin wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> 
> iEYEARECAAYFAk3tf4UACgkQ9RoMZyVa61f0LwCgm4OkWYDf46pZ7GjfPfu93BBJ
> NcUAnAtLP1kTvzZ51F9jTucTUcTp6f9Y
> =kM4T
> -----END PGP SIGNATURE-----
> _______________________________________________
> VIPR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vipr

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Thu, 09 Jun 2011 08:48:42 -0700

> 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 ha…

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.

- -- 
Marc Petit-Huguenin