Subject: [Rserpool] AD comments on draft-ietf-rserpool-policies-06

From: Magnus Westerlund <[email-masked]>
Date: Tue, 16 Oct 2007 18:37:51 +0200

Hi,

Some comments on the policies document

1. In a number of places I find this document talking about policies
returning multiple PEs in answer. However, I can't remember any requests
that support asking for multiple answers. So please inform me how this
was intended to use. Or if not currently supported what the intention
was with specifying this for the policies.

2. Section 5.2.2:
I think one need to clarify that this policy should be selecting the
pool element that gets the lowest value when calculating: load value +
degradation counter * load degradation

Forgetting to multiply the load degradation factor with the counter of
loads assigned I think miss the whole purpose of this policy.

3. Section 5.4.1:
"ratio of 100%-load to
   the sum of all pool elements' load values."

I think you should change this formula. I first interpreted the minus
sign as continunation but that didn't make much sense. Also I think 100%
needs to be represented as it is in the protocol with 0xFFFFFFFF.

Also shouldn't the used ratio be = (0xFFFFFFFF - load_A) /
(sum(0xFFFFFFFF-load_x)) i.e. this PE's unload part related to the whole
pools unload rate. I think that makes more sense than to calculate it as
unloaded divided by the sum of the total load.

4. Section 6.

Shouldn't this section discuss the sensitivity the different policies
has against different type of attacks. For example if an ENRP gets a lot
of requests for a particular pool and it used a least used policy that
requires the PE to update its load, then all these requests will end
pointing to that particular PE. So it is sensitive to flash floods of
requests. I think there are other considerations that also should be
noted about the policies.

5. Section 7.1: I can't understand what the policy is for value
0x80000000-0xFFFFFFFF. Is that also specification required, can't be
registered? To me it seems this range would be best served by first come
first served.

-- 

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: Thomas Dreibholz <[email-masked]>
Date: Tue, 23 Oct 2007 16:26:34 +0200

Hi Magnus,

see my comments inline.

> was with specifying this for the policies.

The ENRP server decides how many PE identities to return upon a handle 
resolution request. Then, the requested number of PE identities is selected 
by policy.

This should be clearified in the ASAP draft.

> loads assigned I think miss the whole purpose of this policy.

Done. The description has been misleading, since "counter" has been increased 
by "load degradation". A counter should be incremented by 1. Therefore, I 
have changed the part as follows:

-----
For every pool element entry, a degradation counter MUST be stored. When
a pool element entry is added or updated by registration or reregistration, 
this counter MUST be set to 0. When an entry is selected for being returned 
to a pool user, the internal degradation counter MUST be incremented by 1. 
The selection of pool element entries is handled like for LU, except that the 
selected pool element entries SHOULD have the lowest possible sum of load 
value + degradation counter * load degradation value.
-----

> unloaded divided by the sum of the total load.

Done.  The description has been changed as follows:

-----
The Randomized Least Used (RLU) policy combines LU and WRAND. That is, the 
pool element entries are selected randomly. The probability for a pool 
element entry A, utilized with load_A, to be selected is (0xFFFFFFFF - 
load_A) / (sum(0xFFFFFFFF-load_x)), i.e. this PE's unload part related to the 
whole pool unload rate.
-----

> noted about the policies.

Policies are affected by misinformation propagated into the handlespace by an 
attacker. This generic security threat is already handled in the Threats 
document.

> registered? To me it seems this range would be best served by first come

The idea of this policy range is to have an ID space which can be safely used 
for private, non-standard policies.

I have replaced "user-defined" by "private use" and also added the following 
sentence:
"The Policy Type space from 0x80000000 to 0xffffffff is designated for private 
use."

Best regards
-- 
=======================================================================
 Dr. Thomas Dreibholz

 University of Duisburg-Essen,                   Room ES210
 Inst. for Experimental Mathematics              Ellernstraße 29
 Computer Networking Technology Group            D-45326 Essen/Germany
-----------------------------------------------------------------------
 E-Mail:     [email-masked]
 Homepage:   http://www.iem.uni-due.de/~dreibh
=======================================================================
_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool