[Gen-art] gen-art review of draft-ietf-rserpool-policies-08.txt

[Elwyn Davies <[e-mail]>]

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

_______________________________________________
Gen-art mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/gen-art