I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
_http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html_).
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-rserpool-policies-08.txt
Reviewer: Elwyn Davies
Review Date: 11 April 2008
IETF LC End Date: 14 April 2008
IESG Telechat date: (if known) -
Summary:
Sorry, guys! This document is not in good shape. I know it is, in a
sense, the bottom of the tree and somebody reading it would probably be
expected to have read in to the subject through the overview (I scanned
it) and the protocol documents (I didn't look at them), but I found the
introduction opaque, for example:
The selection of the pool user is
performed by two different entities.
Which ones? Selection of what? Selection of which pool user to get this
week's star prize?
Enough of irony and sarcasm: I have two big technical questions about
this document (and hence the whole strategy of rserpool):
1. Why do policies appear on the wire in this way? Do the individual
servers care about the policy of the group? Would it conceivably work
if they weren't all conforming to some preconfigured policy? Is this
expected to change over time? Would weights change over time? Seems to
me that policy is a preconfigured characteristic of the group. Maybe
weight is something that a server might communicate during sign on.
Load is dynamic and probably needs to be propagated from time to time.
These are all conflated in these protocol elements. Is this good
design? Who really needs to know about policies dynamically?
2. Why should pool users have to worry about pool policy? They just
want a server. They don't want to have to (and IMO shouldn't have to)
try to second guess the pool controllers by munging around it what was
allegedly already a prioritized list, surely? In order to do this,
especially in the adaptive cases, the pool user needs the weight and
load (according to the policy used) for each server passed in the list
of servers in response to the request on the rserpool server. It isn't
at all clear that this is what happens.
Part of the overall problem is that the document does not clearly state
which communications use these items, why they would need to and how
frequently.
There are also detailed issues with the document, but I have to say that
I cannot see that we currently have an effective technical design. It
is possible that these points have been discussed in the wg; if so some
explanation of the motivation for the arrangement is absolutely
essential. I am happy to revisit this review if the authors can explain
the motivation and suggest text that will get the naive(ish) reader over
the understanding hump.
Comments:
s3.2:
A weight of 0 denotes that the pool element is not capable of
providing any service, a weight of 2*n denotes that the pool element
is capable of providing a two times better service than a pool
element having weight n.
For example, weight may define a compute service's computation
capacity. That is, a pool element of weight 100 will complete a work
package in half of the time compared to a pool element of weight 50.
'two times better'? Any attempt to quantify the meaning of weight
beyond a relative ordering of capability will lead to questions such as
'under what conditions?' Leave it to the servers to make what they will
of weights - that is the best that the protocol can do.
s3 and s4: The encoding of weight and load is not specified other than
implicitly.
s4.1.3: How does the pool user know some information is out of date?
Editorial:
s1: Lots of acronyms need expansion.
idnits reporst reference issues:
Checking references for intended status: Experimental
----------------------------------------------------------------------------
== Unused Reference: 'Dre2006' is defined on line 615, but no explicit
reference was found in the text
'[Dre2006] Dreibholz, T., "Reliable Server Pooling -- Evaluation, Op...'
== Unused Reference: 'LCN2005' is defined on line 623, but no explicit
reference was found in the text
'[LCN2005] Dreibholz, T. and E. Rathgeb, "On the Performance of Reli...'
== Outdated reference: A later version (-16) exists of
draft-ietf-rserpool-common-param-15
== Outdated reference: A later version (-19) exists of
draft-ietf-rserpool-asap-18
== Outdated reference: A later version (-19) exists of
draft-ietf-rserpool-enrp-18
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf