Subject: [Rserpool] ASAP Handle Resolution Option

From: Dirk Hoffstadt <[email-masked]>
Date: Wed, 19 Nov 2008 15:01:34 +0100

Dear all,

What about the draft draft-dreibholz-rserpool-asap-hropt-03
(http://tools.ietf.org/html/draft-dreibholz-rserpool-asap-hropt-03) on
the ASAP Handle Resolution option to specify the requested number of PE
entries to be selected? I think this is a quite useful extension and
should also be moved forward.

In our deployed RSerPool pool for SimProcTC, we do not need the PU-side
handle resolution cache. Therefore, on a handle resolution, the ENRP
server should exactly select one PE entry for the SimProcTC PU. ASAP as
defined in RFC 5352 lacks of the possibility to specify this. The handle
resolution option allows the PU to exactly tell this information to the
ENRP server. So, the ENRP  server can exactly select the one PE entry
for our SimProcPC PU -- while it can provide more entries to PUs
actually making use of the PU-side cache. I see a clear need for
standardization of such an option, since its functionality is IMHO
mandatory for efficient handle resolution.

- --
Best regards,
Dirk Hoffstadt
- ------------------------------------------------------------------
M.Sc. Dirk Hoffstadt
DH Datentechnik
45219 Essen Germany
E-Mail: [email-masked]
Internet: http://www.dhdt.de PGP-PublicKey:
https://dhdt.de/private/dirkhoffstadt_pubpgp.asc
- ------------------------------------------------------------------
_______________________________________________
rserpool mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rserpool

---

From: Thomas Dreibholz <[email-masked]>
Date: Wed, 19 Nov 2008 15:17:37 +0100

> mandatory for efficient handle resolution.

Dear Dirk,

yes, this option is indeed really useful and I also think it is mandatory for 
efficient RSerPool deployment (and therefore, RSPLIB has it built-in, of 
course).

I did some intensive analysis and performance optimization research on the 
RSerPool handlespace management. The results of this work can be found in the 
journal article "An Evalulation of the Pool Maintenance Overhead in Reliable 
Server Pooling Systems", which has been published in the International 
Journal of Hybrid Information Technology (IJHIT), Volume 1, Number 2, April 
2008. This article is available online here: 
http://www.sersc.org/journals/IJHIT/vol1_no2_2008/2%20pp%2017-32.pdf .

In summary: if the ENRP server has no knowledge on how many PE entries to 
select upon a PU's request, it will use an - usually - too high fixed 
setting. In my experience, the PU-side cache is mostly not used (i.e. only 1 
PE entry is needed by the PU) to use the most accurate PE state for adaptive 
policies. But setting the default to 1, it would make the PU-cache useless. 
Therefore, if any of the PUs makes use of its cache, an ENRP server's setting 
must be larger than 1. This implies significant inefficiency for handle 
resolutions by PUs needing only one entry (waste of ENRP server CPU time and 
waste of bandwidth). This problem will be overcome by the usage of the handle 
resolution option, which lets the PU specify its desired number of PE 
entries.

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://www.ietf.org/mailman/listinfo/rserpool

---

From: Nihad Cosic <[email-masked]>
Date: Wed, 19 Nov 2008 15:33:33 +0100

On Mi, 2008-11-19 at 15:01 +0100, Dirk Hoffstadt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Dear all,
> 

Dear Dirk,

during my work with the RSPLIB and FH Münster implementations, I have
also discovered this problem. There is definitely the need for such an
option. And since there are multiple implementations, I also see the
strong need to have this option standardized. Otherwise, each vendor
would make its own, incompatible realization of this functionality. This
situation must be avoided.

Kind regards

Nihad Cosic 
Computer and Network Engineer
University of Duisburg-Essen
Institute for Computer Science and Business Information Systems (ICB)
Ellernstr.29 
45326 Essen, Germany 
Tel: +49 (0) 201 183-7651 
Fax: +49 (0) 201 183-7673 
Mail: cosic at iem.uni-due.de 
PGP-Key http://tdrwww.iem.uni-due.de/mitarbeiter/cosic/pubkey.asc

---

From: "Ong, Lyndon" <[email-masked]>
Date: Wed, 19 Nov 2008 09:58:52 -0500

Hi Folks,

Not to pass judgement one way or another on the handle resolution
option, but I don't see our A-Ds favoring the creation of a new item on
our charter.  I believe the most likely direction forward on this is as
an individual draft rather than a Working Group activity.

I will check with Lars and Magnus, though.

Best regards,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dirk Hoffstadt
Sent: Wednesday, November 19, 2008 6:02 AM
To: [email-masked]
Subject: [Rserpool] ASAP Handle Resolution Option

Dear all,

- --
Best regards,
Dirk Hoffstadt

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 19 Nov 2008 11:03:09 -0600

> I will check with Lars and Magnus, though.

Hi,

The current plan is to shutdown the WG. It has been clear for quite some
long time that the energy level is very low. I intended to keep with the
plan to shutdown the WG. I was seriously considering closing the WG
already before finishing the MIB.

This doesn't prevent that some minor extensions are worked on. I can AD
sponsor appropriate documents. But please remember that we one of the
reasons for closing the WG is that we don't have a lot of support and we
need to see if we get any significant usage before taking up update and
extensions work again.

So no WG item for this work.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
rserpool mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rserpool

---

From: Randy Stewart <[email-masked]>
Date: Wed, 19 Nov 2008 12:30:23 -0500

Magnus:

I really don't understand the usefulness of this extension.

What it does, in a nut shell, is allow the PU requester to
limit the number of responses he is getting...

This can easily be done by:
  - configuring the ENRP server to limit the number of responses
  or
  - configuring the requesting PU side to discard all but the number
    that he wants.
Either way works without changes to the protocol..

R

> IETF Transport Area Director & TSVWG Chair

-----
Randall Stewart
[email-masked]

---

From: Thomas Dreibholz <[email-masked]>
Date: Thu, 20 Nov 2008 09:40:45 +0100

>   - configuring the ENRP server to limit the number of responses

Dear Randy,

this does not work for all pools. If there are PUs in the pool which require 
only 1 PE entry and other PUs in the pool requiring up to 100, the setting 
has to be 100.

>   - configuring the requesting PU side to discard all but the number

Then, the ENRP has to unnecessarily select entries, which wastes a lot of 
processing power and network bandwidth. In summary, it is very inefficient. 
For details, see the performance evaluation in the journal article "An 
Evalulation of the Pool Maintenance Overhead in Reliable 
Server Pooling Systems", which has been published in the International 
Journal of Hybrid Information Technology (IJHIT), Volume 1, Number 2, April 
2008. This article is available online here: 
http://www.sersc.org/journals/IJHIT/vol1_no2_2008/2%20pp%2017-32.pdf .

> Either way works without changes to the protocol.

It works, but it is very inefficient. For a useful deployment of RSerPool, I 
see this option as being absolutely necessary. Therefore, and since there are 
multiple implementations and people are starting to actually use RSerPool, I 
see the need for this document to also become RFC. This will avoid 
incompatibilities among implementations.

Best regards

---

From: Dirk Hoffstadt <[email-masked]>
Date: Thu, 20 Nov 2008 09:59:59 +0100

> http://www.sersc.org/journals/IJHIT/vol1_no2_2008/2%20pp%2017-32.pdf .

Dear Thomas, Randy,

Yes, this is exactly the point I mentioned in my mail yesterday. Such an
option is definitively necessary for efficient RSerPool deployment.

> incompatibilities among implementations.

I fully agree to this point. Without a standardized definition of this
option, each implementor/vendor will sooner or later add such a
functionality to provide efficient PE selection. This will cause
incompatibilities, which must be avoided.

-- 
Best regards,
Dirk Hoffstadt
------------------------------------------------------------------
M.Sc. Dirk Hoffstadt
DH Datentechnik
45219 Essen Germany
------------------------------------------------------------------

---

From: Nihad Cosic <[email-masked]>
Date: Thu, 20 Nov 2008 10:32:57 +0100

Dear Randy,

the problem is that a fixed setting to limit the number of responses
does not work well: some PUs may need a large setting (to utilize the
PU's cache) and some other PUs may need a small setting (usually 1). If
such pools are in the same handlespace, the maximum setting for all PUs
has to be configured. This is really inefficient for all others.

In the RSerPool deployment setup I maintain, there is a large SimProcTC
pool (requiring only 1 PE upon selection, but having a quite high handle
resolution rate) and some other pools (with some PUs using their
caches). Using a large setting for the number of PEs is really
inefficient: it wastes CPU time on the ENRP servers and also network
bandwidth. Currently, I am working on a replacement of the ENRP server
PCs by moving the ENRP server processes to our Linux-based WRT54GL
routers. Such devices only contain a low-performance CPU. Therefore, I
care pretty much for efficiency. The handle resolution option is really
needed for efficient RSerPool operation.

I already work with two implementations - RSPLIB and the FH Münster
package - and see therefore a strong need for this option draft document
to avoid incompatibilities among implementations.

Kind regards

---

From: Randy Stewart <[email-masked]>
Date: Thu, 20 Nov 2008 07:27:19 -0500

> only 1 PE entry and other PUs in the pool requiring up to 100, the  

In this case you can configure it on the PU... its not that big of deal.
Besides if you only want one response, why are you even bothering
to use RSERPOOL. Its just as easy to use either a configured
host or DNS to lookup the single guy you wish to talk to.

> processing power and network bandwidth. In summary, it is very  

This is rather silly in my mind. B/W on a network where rserpool
is running is not going to be that much of a problem IMO. Processing
power is a moot point with multi-gig-hz machines and Gig's of memory
being the common environment. If you are not in that environment
your NOT going to have 100's of PE's so I see NO need for this.

Also your argument here is in direct conflict to the argument above.

> It works, but it is very inefficient.

Here I strongly disagree with you. If you have large numbers
of pools your network and processing capacity will always be
greater than if you have a small rserpool deployment. Being
one of the folks that have truly deployed rserpool back in
99 at Motorola I can tell you that we had NO problem with
either network or bandwidth. And thats not theory but
analysis of a true production system running rserpool....

We DO NOT need this IMO!

IMO I STRONGLY think the WG needs to be closed. And from
what I can see from Magnus's statement:

----
----

He agrees with me... I am all for this plan... finish the MIB and close
the WG.

IF problems arise and there is significant usage in REAL production  
networks
of rserpool that warrant updates to the documents, we can deal with that
on a "as need" basis....

R

> For a useful deployment of RSerPool, I
> = 
> ======================================================================
> Dr. Thomas Dreibholz
>
> = 
> ======================================================================

-----
Randall Stewart
[email-masked]

---

From: Thomas Dreibholz <[email-masked]>
Date: Thu, 20 Nov 2008 13:50:12 +0100

Dear Randy,

the idea is to configure the number on the PU. But the PU has to tell the ENRP 
server how many PE entries it actually needs.

> your NOT going to have 100's of PE's so I see NO need for this.

Bandwidth it not really the problem. The actual problem is the unnecessary 
processing power it needs to select e.g. 100 PEs when e.g. actually only 1 
entry is really required. Why should the ENRP server need significantly more 
CPU resources than necessary when it is so easy to fix this problem? The 
handle resolution option is really simple (just 8 bytes containing a single 
entry) and successfully fixes this problem. With a few lines of 
implementation code, a significant performance gain can be achieved.

Best regards

---

From: "Michael Kohnen" <[email-masked]>
Date: Thu, 20 Nov 2008 14:46:06 +0100

Dear Randy,

The point is that for many applications exactly one PE should be selected
out of a pool (containing many PEs) by the pool policy. That is, there
should be a way to tell the ENRP server to just select a single entry. For
other applications, there should be the possibility to tell the PE to select
more entries (e.g. to utilize the PU cache). If there is a fixed setting of
how many PE entries to reply upon a Handle Resolution Request, this is not
optimal for many applications while it is required for others.

Since RSerPool is intended to be "lightweight", I see the need to take care
of efficiency. Therefore, it is really useful to have this handle resolution
option.

Best regards

Michael Kohnen
-- 
Dipl.-Wirt.-Inf. Michael Kohnen
 
Lehrstuhl für Technik der Rechnernetze
Institut für Experimentelle Mathematik und Institut für Informatik und
Wirtschaftsinformatik
Universität Duisburg-Essen, Campus Essen
Ellernstr. 29
45326 Essen
 
Telefon: +49 (201) 183-7636
Fax: +49 (201) 183-7673
E-Mail: [email-masked]
Homepage: http://www.uni-due.de/tdr/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Randy Stewart
Sent: Thursday, November 20, 2008 1:27 PM
To: Thomas Dreibholz
Cc: [email-masked]; Lyndon Ong
Subject: Re: [Rserpool] ASAP Handle Resolution Option

On Nov 20, 2008, at 3:40 AM, Thomas Dreibholz wrote:

>> What it does, in a nut shell, is allow the PU requester to limit the 
>> number of responses he is getting...
>>
> this does not work for all pools. If there are PUs in the pool which 
> require only 1 PE entry and other PUs in the pool requiring up to 100, 
> the setting has to be 100.
>

In this case you can configure it on the PU... its not that big of deal.
Besides if you only want one response, why are you even bothering to use
RSERPOOL. Its just as easy to use either a configured host or DNS to lookup
the single guy you wish to talk to.

> Then, the ENRP has to unnecessarily select entries, which wastes a lot 
> of processing power and network bandwidth. In summary, it is very 
> inefficient.

This is rather silly in my mind. B/W on a network where rserpool is running
is not going to be that much of a problem IMO. Processing power is a moot
point with multi-gig-hz machines and Gig's of memory being the common
environment. If you are not in that environment your NOT going to have 100's
of PE's so I see NO need for this.

> Evalulation of the Pool Maintenance Overhead in Reliable Server 
> Pooling Systems", which has been published in the International 
> Journal of Hybrid Information Technology (IJHIT), Volume 1, Number 2, 
> April 2008. This article is available online here:

Here I strongly disagree with you. If you have large numbers of pools your
network and processing capacity will always be greater than if you have a
small rserpool deployment. Being one of the folks that have truly deployed
rserpool back in
99 at Motorola I can tell you that we had NO problem with either network or
bandwidth. And thats not theory but analysis of a true production system
running rserpool....

We DO NOT need this IMO!

IMO I STRONGLY think the WG needs to be closed. And from what I can see from
Magnus's statement:

----
The current plan is to shutdown the WG. It has been clear for quite some
long time that the energy level is very low. I intended to keep with the
plan to shutdown the WG. I was seriously considering closing the WG already
before finishing the MIB.
----

He agrees with me... I am all for this plan... finish the MIB and close the
WG.

IF problems arise and there is significant usage in REAL production networks
of rserpool that warrant updates to the documents, we can deal with that on
a "as need" basis....

R

> For a useful deployment of RSerPool, I see this option as being 
> absolutely necessary. Therefore, and since there are multiple 
> implementations and people are starting to actually use RSerPool, I 

-----
Randall Stewart
[email-masked]

---

From: Dirk Hoffstadt <[email-masked]>
Date: Thu, 20 Nov 2008 15:03:44 +0100

> implementation code, a significant performance gain can be achieved.

Yes, I fully agree to that. The solution to solve the "number of PE
entries to be selected" problem by the handle resolution option is
really simple. Wasting resources should really be avoided, since this
reduces deployment costs.

- --
Best regards,
Dirk Hoffstadt

---

From: Michael Tüxen <[email-masked]>
Date: Thu, 20 Nov 2008 08:52:45 -0600

Hi Thomas,

I do understand that the ID is simple, but I'm not sure if this
is really necessary to have for the things that are done *NOW*
using RSerPool.

If you think you need this, you can integrate this in your
implementation and choose the higher bits such that you can
at least interoperate with implementation not supporting your
extension.

So I support Magnus position to close the WG.

Best regards
Michael

---

From: Thomas Dreibholz <[email-masked]>
Date: Thu, 20 Nov 2008 16:03:58 +0100

> is really necessary to have for the things that are done *NOW*

Dear Michael,

it is indeed already needed for deployments *NOW*.

> at least interoperate with implementation not supporting your

This is not a good idea, it will only create unnecessary interoperability 
issues. I think now is the time to define this option, before other people 
discover the same efficiency problem and implement it in a different way. A 
scenario in which multiple ENRP servers first have to figure out the 
capabilities and incompatibilities of their peers should be avoided. This 
makes everything very complicated.

> So I support Magnus position to close the WG.

May be this draft could simply be processed as individual submission.

Best regards

---

From: Dirk Hoffstadt <[email-masked]>
Date: Fri, 21 Nov 2008 10:46:12 +0100

> it is indeed already needed for deployments *NOW*.

Yes, there are already deployments now. It is not useful to wait until
incompatible implementations are widely deployed. Then, it will already
be too late.

> May be this draft could simply be processed as individual submission.

This is a good idea.

The draft is already complete, so I do not see a use in re-submitting it
as WG document. Instead, it can be moved forward as Individual Submission.

---

From: Nihad Cosic <[email-masked]>
Date: Fri, 21 Nov 2008 13:25:15 +0100

Dear Dirk,

I fully agree to this argument.

> as WG document. Instead, it can be moved forward as Individual Submission.

Yes, this seems to be a good idea.

Regards

Nihad Cosic

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 21 Nov 2008 14:04:23 -0600

> as WG document. Instead, it can be moved forward as Individual Submission.

Please note that I said appropriate documents. It is far from clear if
this document is appropriate. I have seen major contributors to RSERPOOL
speak up against it. Also, supporting letters from your colleuges is not
helping to convince me that there is any real support for this option.

Cheers

Magnus Westerlund

---

From: Qiaobing Xie <[email-masked]>
Date: Sat, 22 Nov 2008 14:09:32 -0600

I don't see much usefulness of this new option.

When you want the server to select a few out of all PEs, are you 
thinking of making the server to use some selection criterion? If the 
selection criterion is anything beyond random selection, you are 
actually adding considerable complexity and computational burden to the 
server side. If random selection is what you have in mind, them why not 
do it on the PU side after it receives the all the PEs from the server? 
Implementing on the PU side should be cheaper, transparent, and no need 
for standards.

regards,
-Qiaobing

Dirk Hoffstadt wrote:
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (MingW32)
>
> iQEcBAEBAgAGBQJJJW4/AAoJEAl0PP0XKTexStEIANm2uhUn0JHwHNg9xIBelyHV
> niqhi0zBOsiy36JtoanDLMgFLNd/uzGDBdViX/OLMJFSCuHmEXD3pjA6/avCzY0r
> qL6rHb5pr2yfq6ALqzpQ9yODUFdWH55XSWDQH3aIRhoD74n0L5NvuHHz7g9BNjv5
> uWAiRAL1ljyWfsX6kbaE2iSpwVfg4RUPDCCcgsUcKoPxKR1Y9XFylc97ORWjYz7J
> hH2DkYApT5qIURnp7SU7FIeXRBb0ftXnZlqOdt6oQm4c9dTuojNeZr2XTpEnbQjz
> nMGBk7LmS/4beb2PdQPMl//VjCKh9FrzS4sZWYq0jEc9yCGuJQhg+R+/Qc3EM7g=
> =f1/2
> -----END PGP SIGNATURE-----