2.8.13 Reliable Server Pooling (rserpool)

NOTE: This charter is a snapshot of the 50th IETF Meeting in Minneapolis, Minnesota. It may now be out-of-date. Last Modified: 14-Mar-01

Chair(s):

Lyndon Ong <lyndon_ong@eudoramail.com>
Maureen Stillman <maureen.stillman@nokia.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@east.isi.edu>

Transport Area Advisor:

Scott Bradner <sob@harvard.edu>

Technical Advisor(s):

Ned Freed <ned.freed@innosoft.com>

Mailing Lists:

General Discussion:rserpool@ietf.org
To Subscribe: rserpool-request@ietf.org
In Body: subscribe email_address
Archive: ftp://ftp.ietf.org/ietf-mail-archive/rserpool/

Description of Working Group:

The purpose of the WG is to develop an architecture and protocols for the management and operation of server pools supporting highly reliable applications, and for client access mechanisms to a server pool.

The WG will define architecture and requirements for management and access to server pools, including requirements from a variety of applications, building blocks and interfaces, different styles of pooling, security requirements and performance requirements, such as failover times and coping with heterogeneous latencies. This will be documented in an Informational RFC.
Scope:
The working group will focus on supporting high availability and scalability of applications through the use of pools of servers. This requires both a way to keep track of what servers are in the pool and are able to receive requests and a way for the client to bind to a desired server.
The Working Group will NOT address:
1) reliable multicast protocols - the use of multicast for reliable server pooling is optional. Reliable multicast protocols will be developed by the RMT WG.
2) synchronization/consistency of data between server pool elements, e.g. shared memory
3) mechanisms for sharing state information between server pool elements
4) Transaction failover. If a server fails during processing of a transaction this transaction may be lost. Some services may provide a way to handle the failure, but this is not guaranteed.
The WG will address client access mechanisms for server pools, specifically:
1) An access mechanism that allows geographically dispersed servers in the pool
2) A client-server binding mechanism that allows dynamic assignment of client to servers based on load balancing or application specific assignment policies.
3) Support of automatic reconfiguration of the client/server binding in case of server failure or administrative changes.
To the extent that new protocols are necessary to support the requirements for server pooling, these will be documented in a Standards Track RFC on client access to a binding service (i.e. name space) protocol.
The WG will also address use of proxying to interwork existing client access mechanisms to any new binding service.
The WG will address server pool management and a distributed service to support client/server binding, including:
1) A scalable mechanism for tracking server pool membership (incl. registration)
2) A scalable protocol for performing node failure detection, reconfiguration and failover, and otherwise managing the server pool (supporting caching, membership, query, authentication, and security)
3) A distributed service to support binding of clients to servers, based on information specific to the server pool. Given that this service is essential to access the server pool, a high degree of availability is necessary.
4) A means for allowing flexible load assignment and balancing policies
The protocols and procedures for server pool management will be documented in a Standards Track RFC.
The WG will address:
- transport protocol(s) that would be supported (eg. UDP, SCTP, TCP)
- any new congestion management issues
- relationship to existing work such as URI resolution mechanisms
Rserpool will consult with other IETF working groups such as Reliable multicast, DNS extensions, AAA, URN, WREC and Sigtran as appropriate and will not duplicate any of these efforts.

Goals and Milestones:

Done

  

Initial draft of RSPool Requirements And Architecture document

Jan 01

  

Submit Reqts and Architecture draft to IESG for consideration as an Informational RFC

Mar 01

  

Initial draft of Binding Service document

Jun 01

  

Initial draft of Client/server binding and Server Pool Management document

Sep 01

  

Submit drafts of Binding Service and Server Pool Management to IESG for consideration as Proposed Standard RFCs

Internet-Drafts:
No Request For Comments

Current Meeting Report

Minutes for RSERPOOL at IETF 50

Reported by La Monte Yarroll and Maureen Stillman

Date: Thursday, 22 Mar 2001

Chairs: Lyndon Ong (lyndon_ong@eudoramail.com)
Maureen Stillman (maureen.stillman@nokia.com)

1. Introduction

The group met with approximately 60 people present.

The group is currently running slightly late on a requirements document, but ahead of schedule on inputs for the related protocols.

2. Requirements and Architecture

Michael Tuexen presented the status of work on a requirements and architecture document.

There was considerable discussion:
-- a number of comments were made on the DNS comparison provided in the document and also on other solutions that were not included, such as ISIS or Beowulf.
-- the contributors of ASAP and ENRP noted that they had done a detailed comparison of many different alternatives in the past and identified weaknesses with them.
-- it was pointed out that the primary goal at this time is to specify a set of requirements. Information such as the comparison could be separated out into another document, also the architecture and examples (which are more specifically ASAP and ENRP-oriented) could be split off.
-- It was further noted that ISIS and Beowulf are not available as publically documented open solutions, and may not be suitable for inclusion in comparisons.

Based on discussion, it was agreed to split the requirements and architecture document into three documents: requirements, related work, and architecture.

Comments were mainly against the comparison and architecture, not requirements.

There was a specific comment against the requirement stated for use of SCTP - concerns were expressed that this may inhibit use of Rserpool because of SCTP maturity and availability (although it appears to be the best overall solution for transport). It was agreed to generalize the requirement and take the discussion of SCTP to the list.

The group consensus was to advance the requirements document to last call after the modifications discussed are incorporated and posted to the mailing list.

3. ASAP and ENRP

Randy Stewart and Qiaobing Xie provided a comparison of the ASAP and ENRP proposals against the Rserpool requirements.

A number of issues were raised:
-- how does the application know if a given service is ASAP/ENRP enabled? A: query local ENRP server.
-- server-side server selection may be a good approach, since calculating metrics can be non-trivial. A: not in current design but could be added easily.
-- how much application change is needed in order to use ENRP/ASAP? Copmpatibility with upper layers will be important for quick adoption. A: failures are transparent on the client side, the application mostly needs to use a handle rather than specific address. Change is needed on the server side, to do pooling.
-- note that failover, esp. with security, is a lot of work, due to the need to share state and security information.
-- concern that the name service needs to be careful about security, taking into account the attacks that can be made on naming services.

It was noted that some scalability is supported, but that there will be a tradeoff of scale of an implementation and latency.

Some of the limitations that were identified with the current draft: needs work on interaction with other name services (esp. DNS), also security aspects.

Further comments:
-- some discussion around the namespace that would be supported. The authors concluded that ENRP would not attempt to support a hierarchical name space like DNS, but a flat space of "handles".
-- some discussion around the nature of failover - is the proposal trying to guarantee against any single point of failure? A: Yes, but with some limitations, esp. the state-sharing done by the pool elements is out of scope of this work, also performance will depend on the implementation, e.g., how many servers in the pool. It was noted that the robustness requirement covers this discussion.

4. Wrap-Up

There was consensus to accept ASAP and ENRP as WG drafts and continue to work to enhance them, while also being open to other proposals (however, these must be backed by drafts).

It was noted by the authors that ASAP and ENRP are derived from existing working code in the lab.

Randy and Qiaobing plan to reissue the ASAP and ENRP drafts as WG drafts in the next few weeks, and after this the chairs will organize conference calls to discuss progress and plan work, posting notice of the calls on the list.

The chairs raised the possibility of holding an interim meeting to progress work, but a number of participants voiced concerns with travel budgets, and it was generally agreed that a meeting should only be held when it is clear that there is a productive agenda for face-to-face discussions.

Join 18 million Eudora users by signing up for a free Eudora Web-Mail account at http://www.eudoramail.com

Slides

None received.