[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11

Network Working Group                            J. Loughney (ed.)
INTERNET DRAFT                                         M. Stillman
                                                             Nokia
                                                         M. Tuexen
                                                        Siemens AG
                                                            Q. Xie
                                                          Motorola
                                                        R. Stewart
                                                             Cisco
                                                            L. Ong
                                                            Cienna




Expires October 1, 2001                                May 1, 2001

          Comparison of Protocols for Reliable Server Pooling
                   <draft-ietf-rserpool-comp-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of [RFC2026].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

Abstract

   This document compares some related protocols which overlap the
   Reliable Server Pooling problem space.  It intends to show why these
   protocols are not sufficient to accomplish the task of reliable
   server pooling.


Internet-Draft     Comparison of Protocols for RSerPool     May 1 2001


Abstract..............................................................1
1.  Introduction......................................................3
 1.1.  Overview ......................................................3
 1.2 Terminology .....................................................3
2 Relation to Other Solutions.........................................4
 2.1 CORBA ...........................................................4
 2.2 DNS .............................................................5
  2.2.1 Introduction .................................................5
  2.2.2 Requirements .................................................5
  2.2.3 Technical Issues .............................................5
  2.2.4 Name/Address Resolution ......................................7
 2.3 Service Location Protocol .......................................7
3 Security Concerns...................................................8
4 Acknowledgements....................................................9
5 References..........................................................9
6 Authors' Addresses..................................................9




































Loughney                                                    [Page 2


Internet-Draft     Comparison of Protocols for RSerPool     May 1 2001

1.  Introduction

1.1.  Overview

   In creating a solution to provide reliable server pools, there are a
   number of existing protocols which appear to have similar properties
   as to what RSerPool is trying to accomplish.  This document shows
   why these protocols are not sufficient to meet the requirements of
   Reliable Server Pooling [RSER-REQ].

   This study does not intend to be complete, rather intends to
   highlight several protocols which work group members have suggested.

1.2 Terminology

   This document uses the following terms:

   Operation scope:

   The part of the network visible to pool users by a specific instance
   of the reliable server pooling protocols.

   Pool (or server pool):

   A collection of servers providing the same application
   functionality.

   Pool handle (or pool name):

   A logical pointer to a pool. Each server pool will be identifiable
   in the operation scope of the system by a unique pool handle or
   "name".

   Pool element:

   A server entity having registered to a pool.

   Pool User:

   A server pool user.

   Pool Element Handle (or endpoint handle):

   A logical pointer to a particular pool element in a pool,
   consisting of the name of the pool and a destination transport
   address of the pool element.

   Name Space:

   A cohesive structure of pool names and relations that may be queried
   by an internal or external agent.


Loughney                                                    [Page 3


Internet-Draft     Comparison of Protocols for RSerPool     May 1 2001

   Name Server:

   Entity which the responsible for managing and maintaining the name
   space within the RSerPool operation scope.

1.3 Abbreviations

   DPE:  Distributed Processing Environment

   PE:   Pool element

   PU:   Pool user

   SLP:  Service Location Protocol

2 Relation to Other Solutions

   This section is intended to cover some existing solutions which
   overlap somewhat with the problems space of RSerPool.

2.1 CORBA

   Often referred to as a Distributed Processing Environment (DPE),
   CORBA was mainly designed to provide location transparency for
   distributed applications. However, the following limitations may
   exist when applying CORBA to the design of real time fault-tolerant
   system:

   1.CORBA has not been focused on high availability. The recent
   development of a high availability version of CORBA by OMG may be a
   step in the right direction towards improving this situation.
   Nevertheless, the maturity, implementability, and real-time
   performance of the design is yet to be proven.

   2.CORBA's distribution model encourages an object-based view, i.e.,
   each communication endpoint is normally an object. This level of
   granularity is likely to be somewhat inefficient for designing real-
   time fault-tolerant applications.

   3.CORBA, in general, has a large signature that makes the use of it
   a challenge in real-time environments. Small devices with limited
   memory and CPU resource (e.g., H.323 or SIP terminals) will find
   CORBA hard to fit in.

   4.CORBA has lacked easily usable support for the asynchronous
   communication model, and this may be an issue in many applications.
   An improved API for asynchronous communication has been added to the
   CORBA standards recently, but many, if not most, CORBA
   implementations do not yet support it. There is as yet insufficient
   user experience with it to make conclusions regarding this feature's
   usability.


Loughney                                                    [Page 4


Internet-Draft     Comparison of Protocols for RSerPool     May 1 2001

2.2 DNS

2.2.1 Introduction

   This section will answer the question why DNS is not appropriate as
   the sole solution for RSerPool. In addition, it highlights specific
   technical differences between RSerPool and  DNS.

   During the 49th IETF December 13, 2000 plenary meeting Randy Bush
   presented a talk entitled "The DNS Today: Are we Overloading the
   Saddlebags on an Old Horse?" This talk underlined the issue that DNS
   is currently overloaded with extraneous tasks and has the potential
   to break down entirely due to a growing number of feature
   enhancements.

   One requirement to any solution proposed by RSerPool would be to
   avoid any additional requirements for DNS in order to support
   Reliable Server Pooling. Interworking between DNS and RSerPool will
   be considered so that additional burdens to DNS will not be added.

2.2.2 Requirements

   Any solution for RSerPool should meet certain requirements [RSER-
   REQ].  These requirements are related to DNS.

      Servers should be able to register to (become PEs) and deregister
      from a server pool transparently without an interruption in
      service.

      The RSerPool mechanisms must be able to support different server
      selection mechanisms. These are called server pool policies.

      The RSerPool architecture must be able to detect server failure
      quickly and be able to perform failover without service
      interruption.

      Server pools are identified by pool handles. These pool handles
      are only valid inside the operation scope. Interoperability
      between different namespaces has to be provided by other
      mechanisms.

2.2.3 Technical Issues

   This section discusses the relationship between DNS and the
   requirements for RserPool.

2.2.3.1 Host Resolver Problems

   A major issue that prevents the use of DNS as part of the RSerPool
   solution the issue is the architecture of host resolvers. These are
   stub resolvers - which means that they require their local DNS
   servers to do recursion for them.

Loughney                                                    [Page 5


Internet-Draft     Comparison of Protocols for RSerPool     May 1 2001


   In turn, this implies that setting TTL low or 0 will dramatically
   increase the load not only on the authoritative DNS servers - but
   also on these third party servers.

   A secondary effect of this is that the authoritative DNS will not
   know the IP address of the DNS client - only the IP address of the
   local DNS. This affects the ability to do global load balancing
   correctly.

   There is no way to get around these issues unless you all hosts
   would be full resolvers. Putting full resolvers on newer hosts isn't
   sufficient because the issues would still exist for all the legacy
   systems, which will form the bulk of the host population for years
   to come. The solution is not to use third party servers.

   Additionally, if the client can contact the server directly, then
   the server knows the real IP address of the client. Since there is
   no third party involved, the caching TTL can be set as low as
   desired (even to zero). That will increase load on the server, but
   nowhere else.

2.2.3.2 Dynamic Registration

   Registration / de-registration of servers is needed. It can be done
   with DNS by NOTIFY/IXFR. However, frequent updates and replication
   are incompatible.  This is not a DNS problem per se, but it has an
   effect on DNS as it is deployed.

   RSerPool MUST allow software server entities to register themselves
   with a name server dynamically. They can also de-register themselves
   for purposes of preventative maintenance or can be de-registered by
   a name server that believes the server entity is no longer
   operational. This is a dynamic approach, which is coordinated
   through servers in the pool and among RSerPool name servers.


2.2.3.2 Load Balancing

   RFC 2782 itself points out some of the limitations of using DNS SRV
   for load balancing between servers.

         Weight is only intended for static, not dynamic, server
         selection. Using SRV weight for dynamic server selection would
         require assigning unreasonably short TTLs to the SRV RRs,
         which would limit the usefulness of the DNS caching mechanism,
         thus increasing overall network load and decreasing overall
         reliability.

   Based on this, DNS can only really support stochastic load
   balancing, redirecting clients to servers randomly as various caches
   in various resolvers expire at random (although small) intervals.

Loughney                                                    [Page 6


Internet-Draft     Comparison of Protocols for RSerPool     May 1 2001

   DNS offers excellent network scalability but poor control over load
   balance.

   As mentioned previously, the issue of  doing DNS-based dynamic load
   balancing on short time scales will have impacts on third parties,
   due to the presence of stub resolvers.

2.2.3.5 Heartbeating / Status Monitoring

   DNS does not incorporate an application layer heartbeat.
   Heartbeating would dramatically boost traffic levels, and given the
   unavoidable third party dependencies of DNS, the resulting loading
   would be unacceptable. It is passive in the sense that it does not
   monitor or store information on the state of the host such as
   whether the host is up or down or what kind of load it is currently
   experiencing.

   RSerPool SHOULD monitor the state of each server entity on various
   hosts on a continual basis and can collect several state variables
   including up/down state and current load. If a server is no longer
   operational, eventually it will be dropped from the list of
   available servers maintained by the name server, so that subsequent
   application name queries will not resolve to this server address.

2.2.4 Name/Address Resolution

   The technical requirement for DNS name/address resolution is that
   given a name, find a host associated with this name and return its
   IP address(es). In other words, in DNS we have the following
   mapping:

  -  name -> a host machine
  -  address(es) -> IP address(es) to reach that (hardware) host
     machine

   The technical requirement for RSerPool name/address resolution is
   that given a name (or pool handle), find a server pool associated
   with this name and return a list of transport addresses (i.e., IP
   addresses plus port numbers) for reaching a set of currently
   operational servers inside the pool. In other words, in RSerPool we
   have the following mapping:

  -  name -> a handle to a server pool which is often distributed
     across multiple host machines
  -  address -> IP addresses and port numbers to reach a set of
     functionally identical (software) server entities.

2.3 Service Location Protocol

   SLP is comprised of three components: User agent, service agents and
   directory agents. User agents work on the user's behalf to contact a


Loughney                                                    [Page 7


Internet-Draft     Comparison of Protocols for RSerPool     May 1 2001

   service. The UA retrieves service information from service agents or
   directory agents. A service agent works on behalf of one or more
   services to advertise services. A directory agent collects service
   advertisements.

   The directory agent of SLP functions simply as a cache and is
   passive in this regard. Also, the directory agent is optional and
   SLP can function without it. It is incumbent upon the servers to
   update the cache as necessary by reregistering. The directory server
   is not required in small networks as the user agents can contact
   service agents directly using multicast. User agents are encouraged
   to locate a directory at regular intervals if they can't find one
   initially.

   The most fundamental difference between SLP and RSerPool is that SLP
   is service-oriented while RSerPool is communication-oriented. More
   specifically, what SLP provides to its user is a mapping function
   from a name of a service to the location of the service provider, in
   the form of a URL string. Whether the service provider is reachable
   and how to access it by the URL are out of the scope of SLP.
   Therefore, the granularity of SLP operation is at application
   service level.

   In contrast, what RSerPool provides to its user is a mapping
   function from a communication destination name to a set of routable
   and reachable transport addresses that leads to a group of
   distributed software server entities registered under that name that
   collectively represent the named communication destination. RSerPool
   also takes the responsibility of reliably delivering a user message
   to one of these server entities. What service(s) this group of
   servers are providing at the application level or whether the group
   is just a component of an application service provider is out of the
   scope of RSerPool. In other words, the granularity of RSerPool
   operation is at communication server entity level.

   Moreover, RSerPool is designed to be a distributed fault-tolerant
   and real time translation service. SLP does not state either of
   these as design requirements and thus does not attempt to fulfill
   them. In addition, SLP defines optional security features which
   support authentication and integrity. These are mandatory to
   implement but optional in terms of use. RSerPool has stronger
   security requirements.

   The SLP directory agent does not support fault tolerance or
   robustness in contrast to the name servers which do support it.  The
   name servers also monitor the state of the servers which are
   registered in the pool but the SLP directory agents do not perform
   this function. SLP uses multicast and in RSerPool multicast is
   optional.

3 Security Concerns


Loughney                                                    [Page 8


Internet-Draft     Comparison of Protocols for RSerPool     May 1 2001

   This type of non-protocol document does not directly affect the
   security of the Internet.

4 Acknowledgements

   The authors would like to thank Bernard Aboba, Matt Holdrege,
   Christopher Ross, Werner Vogels and many others for their
   invaluable comments and suggestions.

5 References


   [RSER-REQ]     Tuexen, M. et. al, "Requirements for Reliable Server
                  Pooling" <draft-ietf-rserpool-reqts-02.txt>, Work in
                  Progress, April 2001.

   [RFC793]       J. B. Postel, "Transmission Control Protocol", RFC
                  793, September 1981.

   [RFC959]       J. B. Postel, J. Reynolds, "File Transfer Protocol
                  (FTP)", RFC 959, October 1985.

   [RFC2026]      S. Bradner, "The Internet Standards Process -
                  Revision 3", RFC 2026, October 1996.

   [RFC2608]      E. Guttman et al., "Service Location Protocol,
                  Version 2", RFC 2608, June 1999.

   [RFC2719]      L. Ong et al., "Framework Architecture for Signaling
                  Transport", RFC 2719, October 1999.

   [RFC2782]      A. Gulbrandsen et al., "A DNS RR for specifying the
                  location of services (DNS SRV)", RFC 2782, February
                  2000.

   [RFC2960]      R. R. Stewart et al., "Stream Control Transmission
                  Protocol", RFC 2960, November 2000.

6 Authors' Addresses

John Loughney                 Tel.: +358 40 749 9122
Nokia Research Center         e-mail: john.loughney@nokia.com
PO Box 407
FIN-00045 Nokia Group
Finland

Maureen Stillman              Tel.:   +1 607 273 0724 62
Nokia                         e-mail: maureen.stillman@nokia.com
127 W. State Street
Ithaca, NY 14850
USA


Loughney                                                    [Page 9


Internet-Draft     Comparison of Protocols for RSerPool     May 1 2001

Michael Tuexen                Tel.:   +49 89 722 47210
Siemens AG                    e-mail: Michael.Tuexen@icn.siemens.de
ICN WN CS SE 51
D-81359 Munich
Germany

Qiaobing Xie                  Tel.:   +1 847 632 3028
Motorola, Inc.                e-mail: qxie1@email.mot.com
1501 W. Shure Drive, #2309
Arlington Heights, Il 60004
USA

Randall Stewart               Tel.:   +1 815 477 2127
Cisco Systems, Inc.           e-mail: rrs@cisco.com
24 Burning Bush Trail
Crystal Lake, Il 60012
USA

Lyndon Ong
Cienna

































Loughney                                                    [Page 10]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/