Subject: Re: Review of draft-ietf-webdav-quota-02.txt

From: Chris Sharp <[email-masked]>
Date: Thu, 11 Dec 2003 10:30:29 -0800

Just getting around to understanding this thread. I totally agree, the 
quota-assigned-bytes seems unnecessary and confusing.

On another note, I think there needs to be some clarification the way 
quota-available-bytes and quota-used-bytes work.

Example:

Initial State of Repository with a Quota management system:

DAV:quota-available-bytes   DAV:quota-used-bytes
         /A                                                     95MB     
                                     5MG <--- used for somewhere for 
something
         /A/UploadDirectory                      10MB                    
                       0

A new 5MB resource is created at  /A/UploadDirectory/new5MBFile:
                                                                  
DAV:quota-available-bytes   DAV:quota-used-bytes
         /A                                                     90MB     
                                     10MB
         /A/UploadDirectory                      5MB                     
                        5MB

Pretty clear, however, if there is no quota differentiation on 
/A/UploadDirectory, the current draft of the RFC makes 
quota-used-bytes, which is really inherited from its parent, 
incongruent with quota-available-bytes on the same resource. A diagram 
is in order:

Initial State of Repository with a Quota management system:
(quota system on /A only)
                                                                  
DAV:quota-available-bytes   DAV:quota-used-bytes
         /A                                                     95MB     
                                     5MG

A new 5MB resource is created at  /A/UploadDirectory/new5MBFile:
                                                                  
DAV:quota-available-bytes   DAV:quota-used-bytes
         /A                                                     90MB     
                                     10MB
        /A/UploadDirectory                       90MB                    
                      5MB

The sum of quota-available-bytes and quota-used-bytes is 95 on  
/A/UploadDirectory and not 100! Logically, if you get a request for 
quota-available-bytes on a resource /A/UploadDirectory and the quota is 
actually enforced on the parent, that you would essentially walk up the 
tree until you found an appropriate "mount point" based quota 
requirement. If this is true, the quota-used-bytes should do the same 
thing. Meaning, quota-used-bytes on  /A/UploadDirectory would be the 
same as quota-used-bytes /A if /A/UploadDirectory did not contain a 
more specific quota rule.

This is also an efficiency win for implementors. If an implementation 
has to support quota-used-bytes on an arbitrary URL, it is impractical 
to think that quota-used-bytes could be incrementally adjusted and 
would necessarily need to be calculated on-the-fly, which does not 
scale well for most implementations.

How NFSv4 handles this situation?

Also, under the "Notes" section, "What clients should expect" seems to 
have a sentence which is not grammatically correct.
"This allows the space used by /~milele/public/ to be as
     large as the quota on /~milele/ allows (depending on the other
     contents of /~milele/) even if the quota on /~milele/ is changed."

Regards,

Chris.
On Nov 14, 2003, at 2:27 AM, Stefan Eissing wrote:

>
> Brian,
>
> I put my mind into blank slate mode and read the draft 2 for the first 
> time.
>
> I think it is a big improvment from where we started from. One item I 
> found
> confusing though and that is the example for DAV:quota-assigned-bytes
> (and the mental model behind the example).
>
> The draft seems to say that /A and /A/B have separate 
> DAV:quota-assigned-bytes
> properties, however they are in the same "set of collections" when the 
> value
> of DAV:quota-available-bytes/DAV:quota-used-bytes is computed.
>
> (See definition of "set" in the explanation to DAV:quota-used-bytes - 
> seems to
> be a copy from the NFS spec.)
>
> In NFS-Quota, the model seems to be simple: each quota applies to a set
> of collections/files and each member of this set would report the same
> quota properties.
>
> In WebDAV-quota (draft-2): there is a separate quota for each 
> collection
> (e.g. the assigned-bytes), but available-/used-bytes are the same for
> resources in the same set.
>
> Two Problems come to my mind now:
> 1) If a collection of the "set" has the DAV:quota-assigned-bytes not
>   explicitly set, what value would it report? Say for /A/C, /A/B/D and
>   /E (all in the same set)?
>
> 2) If a client wants to increase DAV:quota-available-bytes in a certain
>   collection, it has to increase the DAV:quota-assigned-bytes. But in
>   your example: increasing assigned-bytes on /A/B will not have any
>   effect on the DAV:quota-available-bytes. What is a generic client 
> supposed
>   to do then?
>
> Best Regards, Stefan
>
> Am 13.11.2003 um 22:06 schrieb Brian Korver:
>
>>
>> On Thursday, November 13, 2003, at 01:14  PM, Julian Reschke wrote:
>>> Brian,
>>>
>>> when I re-raised these issues, I *did* read the current draft. So I 
>>> think it's up to you to go back to the mailing list discussion and 
>>> explain why the concerns raised by Stefan and myself aren't valid.
>>>
>>> Julian
>>
>> Julian,
>>
>> I'm planning to do so in today's meeting, but to restate for the 
>> mailing list,
>> Stefan pointed out that if we used quota-limit, then quota-limit 
>> would not be
>> a fixed value (which is the reason we defined things in terms of 
>> quota-limit
>> to begin with).  Thus, instead of quota-limit, the new draft uses 
>> NFS's
>> quota-available.  This has the semantics that it isn't fixed.  
>> Problem solved.
>> Note, quota-available is consistent with the rest of the the quota 
>> definitions
>> we pulled from NFS, so it's conceptually attractive too.
>>
>> I still don't know what you find confusing, so I can't comment on 
>> that yet.
>>
>> -brian
>> [email-masked]
>

---

From: Brian Korver <[email-masked]>
Date: Thu, 11 Dec 2003 10:53:11 -0800

> quota-assigned-bytes seems unnecessary and confusing.

It does seem to be confusing to people.  Do you have a proposal for an
alternative mechanism (or at least wording) that accomplishes
the same thing?  Specifically, a mechanism set the quota (especially in
face of quota systems like the one you give in the example where
quota constraints are inherited from the parent)?

> incongruent with quota-available-bytes on the same resource.

That's just one example of a quota system.  As the draft points out:

    Note that this is only one example quota system, and that other
    quota systems are possible.

Do you think the text would benefit from having an example given using
a different quota system?  I'm starting to think that would be a good
idea.

The draft does not mandate any particular quota system.  IMHO it would
be a bad idea to do so.

>  A diagram is in order:
> quota-available-bytes on a resource /A/UploadDirectory and the quota 
> is actually enforced on the parent, that you would essentially walk up 
> the tree until you found an appropriate "mount point" based quota 

-brian
[email-masked]

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 12 Dec 2003 10:32:10 +0100

Chris,

I agree to your analysis that the current definitions lead to 
confusion. The way out
is to simplify the underlying model.

Definition: a "quota space" is a storage area on the server where 
allocation can
be restricted. All collections on a server either belong to a 
particular quota space
or to no quota space at all (in which case storage allocation, if 
possible, in such
collections cannot be controlled by quotas).

Corollary1: all collections of a particular quota space report the same 
values for
their DAV:quota* properties.

Corollary2: all resources belong to the same quota space as their 
parent collection(s).

Corollary3: all collections which may contain bindings to the same 
resource do
belong to the same quota space. Collections in different quota spaces 
cannot
have bindings to the same resource.

With this model, /A and /A/UploadDirectory will either have the same 
DAV:quota*
values or totally unrelated ones, depending if the two collections 
belong to the
same or to different quota spaces. Thus the problem of "it does not sum 
up" is
avoided. Also, server side implementation can be much simpler, as the 
hiearchies
(e.g. bindings) of collections and resources do *not* influence the 
quota values.

//Stefan

Am 11.12.2003 um 19:30 schrieb Chris Sharp:

>> I put my mind into blank slate mode and read the draft 2 for the 
>> first time.
>>
>> properties, however they are in the same "set of collections" when 
>> the value

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 12 Dec 2003 10:05:12 -0500

I assume in Corollary2, by "all resources", 
you mean "all non-collection resources" ?

Cheers,
Geoff

---

From: Stefan Eissing <[email-masked]>
Date: Fri, 12 Dec 2003 16:16:41 +0100

Finally someone is paying attention!

> you mean "all non-collection resources" ?

Yes, of course, as usual, you are right.

Newly created collections also belong to the same
quota space as their parents.

BR, Stefan

---

From: Brian Korver <[email-masked]>
Date: Fri, 12 Dec 2003 12:24:28 -0800

> collections cannot be controlled by quotas).

Finally, the definition of "quota space".

>
> Corollary1: all collections of a particular quota space report the 
> same values for

That was the implicit model of the original spec (when quotas were on
directories only).  I think this is a good simplification.

> have bindings to the same resource.

I have several problems with this.  First, I believe it implicitly 
forbids
soft-link type binding models.  Did you mean here only the binding model
spelled out in the current binding draft?  Second, it forbids quota 
models
that some vendors support (and have customers that find useful).

> same or to different quota spaces. Thus the problem of "it does not 
> sum up" is

-brian
[email-masked]

---

From: Geoffrey M Clemm <[email-masked]>
Date: Fri, 12 Dec 2003 17:56:32 -0500

I believe it is extremely probable that Stefan was using
the word "binding" as it is defined by the WebDAV binding protocol.
So this definition does not implicitly forbid (or say anything about)
soft-links (which are redirect references, not bindings).

WRT to modeling all possible quota models, one always has to 
balance the simplicity of the model with the flexibility of the
model (in the case of the ACL spec, we ended up being directed
to decrease the flexibility in order to increase the simplicity).

How widespread are the examples of repositories that let you bind
(in the binding protocol sense of the term "bind") a resource
into two collections that are in different quota spaces?

Cheers,
Geoff

---

From: Julian Reschke <[email-masked]>
Date: Sat, 13 Dec 2003 14:11:08 +0100

Just to restate, here are other issues that make the spec more 
complicated than it needs to be and/or incomplete:

- The spec tries to make handling of quotas simple by just reporting a 
single quota, selected by the server (just like in NFS). This is fine as 
long as the information is only used for display in the UI or for 
diagnostics. However, it fails completely if you want to make the quota 
authorable, because in this case you have no control whatsoever about 
*what* quota you're trying to change. I think this is the cause for most 
of the confusion about the "third" property. The simplest way to fix 
this is to remove support for authoring quota values from the spec.

- Disk limits are not quotas. Treating disk limits the same way causes 
funny effects. In addition, method failures due to physical storage 
limits should be treated differently (for instance, when mapping to a 
Unix FS like in the MacOS X driver, you may want to map to two separate 
error codes). IMHO the spec should clearly state that disk limits are 
*not* quotas. If it adds live properties and precondition/postcondition 
names to marshall to disk limit information *separately*, that'll be 
fine as well.

Regards, Julian

-- 
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760