Hi Elwyn,
see my comments in-line.
Best regards
Michael
On Apr 11, 2008, at 2:30 PM, Elwyn Davies wrote:
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
Yes, it assumes that you have read the ASAP and ENRP documents...
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?
The sentence is wrong and has been changed to
The selection of the pool element is performed by two different
entities,
the ENRP server and the pool user.
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
Yes, they do. They all use the same policy (with possibly different
paraeters).
if they weren't all conforming to some preconfigured policy? Is this
expected to change over time? Would weights change over time?
Seems to
The parameters may change over time.
me that policy is a preconfigured characteristic of the group. Maybe
Preconfigured would be static.
weight is something that a server might communicate during sign on.
Load is dynamic and probably needs to be propagated from time to time.
Yes.
These are all conflated in these protocol elements. Is this good
design? Who really needs to know about policies dynamically?
Every node, which does the pool element selection: ENRP server and
Pool user. So it must be communicated.
2. Why should pool users have to worry about pool policy? They just
Because they can do the pool element selection.
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,
Normally the pool elements do the selection. It is only an option for
the ENRP servers to not give out the complete list.
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.
This is described in the protocol documents. This document describes
only
the policies, not how the stuff is communicated or used.
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.
I guess the problem is that at least some of the things you are missing
are contained in the protocol documents. this document only focuses on
the policies, the protocols actually work with arbitrary policies.
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.
Clarified that.
s3 and s4: The encoding of weight and load is not specified other than
implicitly.
They are encoded as an 32 uint, network byte order. Text added.
s4.1.3: How does the pool user know some information is out of date?
The ASAP document describes that it is possible for a PU to cache
this information. The entries must be flushed after some time. This
is when the information is out of date. When this happens depends on
the application. See the references papers.
Editorial:
s1: Lots of acronyms need expansion.
Done.
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...'
Fixed.
== 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...'
Fixed.
== Outdated reference: A later version (-16) exists of
draft-ietf-rserpool-common-param-15
Due to sequential submission and usage of xml2rfc.
== Outdated reference: A later version (-19) exists of
draft-ietf-rserpool-asap-18
Due to sequential submission and usage of xml2rfc.
== Outdated reference: A later version (-19) exists of
draft-ietf-rserpool-enrp-18
Due to sequential submission and usage of xml2rfc.
I have submitted a new version which addresses your comments as
described above.
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
IETF mailing list
IETF(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf