Current Meeting Report
Slides


2.8.13 Reliable Server Pooling (rserpool)

NOTE: This charter is a snapshot of the 54th IETF Meeting in Yokohama, Japan. It may now be out-of-date.

Last Modifield: 05/06/2002

Chair(s):
Lyndon Ong <lyong@ciena.com>
Maureen Stillman <maureen.stillman@nokia.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
A. Mankin <mankin@isi.edu>
Transport Area Advisor:
Scott Bradner <sob@harvard.edu>
Technical Advisor(s):
Ned Freed <ned.freed@mrochek.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
Done  Submit Reqts draft to IESG for consideration as an Informational RFC
Done  Initial draft of Binding Service document
Done  Initial draft of Client/server binding and Server Pool Management document
NOV 01  Submit Architecture draft to IESG for consideration as an Informational RFC
JAN 02  Submit drafts of Binding Service and Server Pool Management to IESG for consideration as Proposed Standard RFCs
Internet-Drafts:
  • - draft-ietf-rserpool-arch-03.txt
  • - draft-ietf-rserpool-comp-04.txt
  • - draft-ietf-rserpool-asap-04.txt
  • - draft-ietf-rserpool-enrp-03.txt
  • - draft-ietf-rserpool-common-param-00.txt
  • - draft-ietf-rserpool-mib-00.txt
  • Request For Comments:
    RFCStatusTitle
    RFC3237 I Requirements for Reliable Server Pooling

    Current Meeting Report

    Minutes of Rserpool
    IETF #54 Japan Monday, July 15, 2002 1530-1730
    Co-chairs:
    Lyndon Ong, lyong@ciena.com
    Maureen Stillman, maureen.stillman@nokia.com

    Approximately 40 people attended this meeting.

    Agenda
    1) Interim meeting - Maureen Stillman

    2) Rserpool services and TCP mapping - Peter Lei
    http://www.ietf.org/internet-drafts/draft-conrad-rserpool-service-02.txt
    http://www.ietf.org/internet-drafts/draft-conrad-rserpool-tcpmapping-00.txt

    3) ASAP - Peter Lei
    http://www.ietf.org/internet-drafts/draft-ietf-rserpool-common-param-00.txt
    http://www.ietf.org/internet-drafts/draft-ietf-rserpool-asap-04.txt
    4) Reliable Server pool applicability statement - Lode Coene
    http://www.ietf.org/internet-drafts/draft-coene-rserpool-applic-00.txt
    5) ENRP - Lode Coene
    http://www.ietf.org/internet-drafts/draft-ietf-rserpool-enrp-03.txt
    6) Comparison document - John Loughney
    http://www.ietf.org/internet-drafts/draft-ietf-rserpool-comp-04.txt

    7) Closing remarks
    co-chairs

    1. Interim meeting - Maureen Stillman

    A Rserpool meeting was held in Herndon, Virginia in May. Extensive meeting notes were published and sent to the list.

    Major Rserpool addition - primitive services for the applications were added by request of John Loughney. We ask that you read the services internet-draft document and determine if the services are useful to the application.

    There was some discussion on how to register a PE with an ENRP server. Should the PE send separate registrations for each transport, or send a list of transports supported (SCTP/TCP)? Terminology consistency across the Rserpool documents will be important. Results of the interim meeting were documented in internet drafts released before this meeting. There are more updates that will be released after the Japan meeting.

    New internet-drafts and Rserpool milestones

    A number of new internet-drafts have been generated as a result of recent changes to the Rserpool protocol. In addition, we have generated a security threat internet-draft. The area directors have advised the chairs to revise the Rserpool milestones and include these new documents. Upon their approval, these new documents can be added as WG items.

    The Rserpool services document open issues were discussed. The WG was instructed by the chair to review this document and determine if these are the correct set of services to be offered to the applications. Comments should be forwarded to the list on this topic and on the specific open issues.

    2) Services - Peter Lei
    http://www.ietf.org/internet-drafts/draft-conrad-rserpool-service-02.txt

    This internet draft is not finished product. There have been major change to the two modes defined previously. The original name service and failover were too constraining. Instead the service document will focus on a menu of services for the application. The goal is to define primitive services for the application. Application layer TCP and UDP interactions between PU and PE to be supported. The document describes two scenarios that satisfy very different requirements.

    Transport layer mappings are what the transport layer must provide to the ASAP and upper layers. Some of the issues concerning what to provide with those mappings follow. The mapping can provide services for automatic or non-automatic failover. In other words, the failover can be done without the application layer getting involved or only if the application layer is programmed to perform failover.

    There is an issue concerning the fact that the transport layer ACK does not necessarily mean that the application received the data. Therefore an upper layer/application level ACK is a significant reliability issue. Do we need both application layer and transport layer ACKs? How will Rserpool do retransmission/congestion control otherwise?

    SCTP allows you to retrieve message that are queued but not sent and sent but not ACKed. We need to add support for these services to the TCP mapping layer.

    Both control and data need to be exchanged between PUs and PEs. The issue is whether or not to multiplex control and data streams. Should this be optional or required?
    TCP transport mapping requirements. The TCP mapping must support message framing; retrieval; heartbeat and streams. These features present in SCTP and need to be added to TCP using mapping.

    Open issues on requirements: Do we need tunable timers? Tunable number of retransmissions? Use of Transmission Sequence Number (TSN) with upper layer acknowledgements?

    TCP Mapping - Peter Lei
    http://www.ietf.org/internet-drafts/draft-conrad-rserpool-tcpmapping-00.txt

    This internet draft describes a mapping layer over TCP which provides the application SCTP-like features. It requires some updating of references and it will be released again after this meeting.

    3) ASAP - Peter Lei
    http://www.ietf.org/internet-drafts/draft-ietf-rserpool-common-param-00.txt
    http://www.ietf.org/internet-drafts/draft-ietf-rserpool-asap-04.txt

    The common parameters draft was created to centralize terms and definitions. This avoids the problem of them getting out of synch in various documents.

    Open issues concerning business cards were mentioned as described in the architecture and services document. Business cards provide common search order for finding an alternate middle server in the case of a tandem relationship where the middle server fails. An example based on prior experience was a CDMA service was discussed in detail at the interim meeting. The details of the business cards need to be finalized.

    The latest ASAP draft added support of other options for PU-PE transport, notably TCP. A Registration_Response message was added and a re-registration procedure has been defined. Next steps for the document are to separate into subsections, PU-ES vs. PE-ES services. Application layer ACKs will be added. Details of "business card" idea ( failover of tandem PU-PE cases) will be fleshed out in the next version of the document..

    4) Reliable Server pool applicability statement - Lode Coene
    http://www.ietf.org/internet-drafts/draft-coene-rserpool-applic-00.txt

    The group did not consider this as a WG item yet as it is incomplete. We will hold off on agreement as WG item as we discuss with A-Ds new documents for the Rserpool WG milestones.

    5) ENRP - Lode Coene
    http://www.ietf.org/internet-drafts/draft-ietf-rserpool-enrp-03.txt

    Open issues in ENRP including PE registration.
    The issue is whether a PE that supports both TCP and SCTP should register once with an ENRP server with a list of transports that it supports OR the PE
    should register once for each separate transport. There are pos and cons to each approach. A good analogy is that the PE is an animal with several legs. Each leg represents a different transport address. If the PE registers once, then if one leg of the animal is dead, you can infer that the whole animal might be dead and avoid that PE on failover. However, if the PE registers each leg separately, then you cannot tell which legs belong to the that animal. You will just try some other leg. In doing so, you might get the same PE (animal) but use a different transport. Chances are that it is also dead. A smarter strategy is to try another PE (animal) first and then if you exhaust all other PEs (animals), then go back and try another leg on the first animal. Animal might be ill, but not dead.

    Algorithms for maintaining the consistency of the ENRP database were discussed. Some issues are the synchronization of servers and auditing of the name space -- should it be a robust or simple mechanism?

    ASAP and ENRP protocol development will continue.

    6) Comparison document - John Loughney
    http://www.ietf.org/internet-drafts/draft-ietf-rserpool-comp-04.txt

    Version 4 is now the latest. It describes the history of why this protocol versus DNS, Corba, SLP, etc. There have been several editorial changes, plus a change to the text on CORBA. There are several CORBA issues. It is complex compared to IETF protocols and hard to fit together. There are some vendor dependencies (ORB vendor).
    There is limited applicability document or interest from the CORBA group to explain how it could be used for reliable server pooling.

    It is the opinion of the chairs that this document is ready for last call as an Informational RFC. This last call will begin on the list following IETF #54.

    7) Closing remark on UDP - co-chairs

    We met with the area directors and discussed the use of UDP in Rserpool. Under their guidance, we have decided not to support UDP as part of the Rserpool infrastructure. What this means is that UDP can be used by applications in PU-PE communications, but not for communications between PU-ENRP servers or PE-ENRP servers. All ENRP server communication must be done with SCTP or TCP as transport. As a result, we will not define a UDP mapping for Rserpool. The rationale for this decision is the concern that UDP does not support congestion control mechanisms. This causes us to discourage its use in defining new protocols. This philosophy is discussed in RFC 2914 entitled "Congestion Control Principles".

    End of minutes


    ----------------------------------------------------------
    Rserpool Interim meeting minutes - May 29-30 Herndon, VA

    We would like to thank the host, Cisco and Ken Morneault for working out the
    details.

    There were many action items generated as a result of this meeting. The group
    felt that we made significant progress. A new set of internet drafts will be
    generated as a result of these discussions. The target deadline is by the end of
    June so that there will be time for review of the drafts before we meet in Japan
    at IETF #54. Please feel free to comment on these minutes and continue
    discussion of the internet drafts on the list.

    Please understand that any consensus reached in this meeting is not regarded as
    the full consensus of the Rserpool WG. All new internet drafts generated as a
    result of these discussions are subject to review, comment and modification.

    Attendees:
    Lode Coene
    Phillip Conrad
    Michael Tuexen
    Randall Stewart
    Peter Lei
    Ken Morneault
    Jaiwant Mulik
    Maureen Stillman, co-chair
    Qiaobing Xie

    Minutes by Lode Coene and Maureen Stillman

    Wed. May 29 9AM
    Introduction and Agenda bashing

    Wed. AM
    1) http://www.ietf.org/internet-drafts/draft-conrad-rserpool-service-00.txt
    Phillip Conrad

    Wed. PM
    2) http://www.ietf.org/internet-drafts/draft-ietf-rserpool-common-param-00.txt
    http://www.ietf.org/internet-drafts/draft-ietf-rserpool-asap-03.txt
    Randy Stewart

    Wed. PM
    3) http://www.ietf.org/internet-drafts/draft-ietf-rserpool-enrp-03.txt
    Qiaobing Xie

    Thurs May 30 AM
    4) http://www.ietf.org/internet-drafts/draft-ietf-rserpool-arch-02.txt
    Michael Tuexen

    Wrapup 11AM

    1) draft-conrad-rserpool-service-01.txt
    draft-conrad-rserpool-tcpmapping-01.txt

    Goal:
    Support transport other than SCTP for devices without SCTP yet
    PU-PE communication
    PU-ES communication

    Could be SCTP and TCP -- both can be supported by a single PE.
    Provide a migration path, via adaptation
    The adaptation layer also clarifies the service to the upper layers.

    Assumptions

    - certain failover model is assumed by the drafts
    - that particular failover model relies on certain features of SCTP which are
    not present in other transport protocols (example message delimitation is not
    present in TCP)
    - define an adaptation (TCP) with shim layers. For other protocols, such as the
    GRE-GPRS IP tunneling protocol is not easy.

    - open issue: tunable timers for heartbeats, number of retransmissions
    - streams may be necessary for ASAP control and application multiplexing
    - service mode and failover service
    - new service primitives for failover mode: failover callback: a hook for doing
    the changeover
    - is a local function done in user space. should be provided by the application
    - should send a message(or more)
    - protocol!?
    No consensus reached. This is to be determined.
    Note: although failover is in scope, state sharing is out of scope. Here is
    where the two features meet.
    - nameservice mode translation call poolhandle -IP address, pool element handle

    Features
    - message orientation
    - heartbeating - tunable timers and parameters for heartbeat
    - detect when a failure has happened in a more timely fashion
    - adapt with a shim layer to do what we need it to do
    - TCP is OK but for other protocols this is not so easy
    - report failure and pick the next server

    Name service mode defined:
    Easy migration path. Take an existing application
    Do a couple of tweaks. Don't have to change their application layer at all.
    Name a group of servers. Use server selection algorithm.
    Report failures.
    Add a few primitives.
    Tell the ASAP layer, this is the pool that I want, please give me a server.
    This server I was talking to failed, please give me another one.

    State sharing out of scope, but Rserpool provides hooks:
    Callback (optional): Failover from this PE to that PE
    Look at whatever state I have in the app that I need to send to my server to
    establish the context to properly
    interpret callback part of application. Could be a return OR could be -- here is
    a stateblob

    ASAP can use retrieval to get unacknowledged messages
    will resend them after I get the new pool element
    call back will get invoked and maybe send a message or 2

    There is a rich set of valuable services that they can get using Rserpool.
    However, in name service mode they won't get everything. For example, they won't
    get auto failover.

    - already existing applications using the ASAP and ENRP will NOT get automatic
    failover: needs changes to your application program.
    - new applications will get the "whole" Rserpool deal if they choose to do so.

    Provide an easy migration path where you don't have to change the application
    transport layer interaction much.

    We discussed the fate of the services document. Should it be merged with ASAP,
    architecture or informational on its own?
    We didn't come to any consensus on this. (Editor's note: for now we will just
    leave it as is)

    Failover mode defined:
    New apps developed. Willing to go and make some mods to the application.
    Failover mode. Requires certain things be there in the underlying transport.

    Name Service mode:
    need full ASAP implementation
    Don't need mapping protocol if you use name service mode
    With the exception PU to ES over TCP mapping layer may be there (??) open issue
    Mapping is not used for the PU to PE communication

    Action item: Section of the text to delete: on selection of pools
    Common parameters document - Qiaobing Xie

    - common API for talking between PU and PE: is not a protocol specification yet
    Commmon API is nice idea

    Issue with retrieval:

    ACK sent back after it is delivered by the kernel
    this does not mean that it got to the application

    - generic acknowledgment problem: if a msg is acknowledged by a layer, that does
    not mean that the layer above you has received it, processed it or done
    something with it.

    MGCP request-response messages
    In some protocols you already have application level ACKs such as MGCP

    So they do only need name service part of rserpool. Rserpool is a framework from
    which you can choose.
    - notion: if failover occurs, retrieval and send msg to other server.

    Retrieval is a optional service, SCTP retrieval is broken.-msg is only
    acknowledge by its own layer, the upper layer retrieving the msg doesn't know
    which msg was received by it peer layer, except by explicit own layer
    acknowledgement. (otherwise msg duplication or loss....). The retrieval service
    provided (based on application ack) by Rserpool is a greater convenience than
    SCTP retrieval

    Retrieval function in ASAP can be turned on or off.
    If your protocol already supports application level ACK then you can turn it off


    MGCP is a good candidate for name service only mode.
    Some application have application acknowledgement in its protocol(example
    MEGACO), so they do only need name service part of rserpool. Rserpool is a
    framework from which you can choose.

    The group recognized there is a problem:

    Currently, in the ASAP document there is a flag that allows you to turn on the
    retrieval inside ASAP.
    This feature is optional. Due to the acknowledgement problem it is broken.
    Options are:
    1) Fix it.
    2) Don't use it.
    3) Use it, but know it is broken.
    4) Use application layer ACKs and take it out
    Fix it. If you already have app set, then use name service mode, but don't
    enable retrieval.

    Broken -- when ASAP does retrieval
    When the ASAP gets back an ACK from SCTP, this tells me it got part of the way
    there, but not all the way there.
    Want to know did they get all the way there. Did the application actually get
    the message and process it?

    We have a vague notion of how retrieval will work.
    Some applications don't need it.

    For some applications (protocols) it is better to lose messages than to process
    a message twice.
    App has to deal with message loss. Can't find a solution???

    One option is to let the app call back mechanism handle this
    everything you don't have an ACK for try again

    debating a failover service
    edge of the charter, not clear where the boundary is solving the problem of
    transaction integrity providing some hooks

    how far to go and what those hooks should be

    where we are today isn't good
    need to go further or back away
    now at a place that doesn't make sense

    We don't want to give people the illusion that we have solved the problem when
    we haven't understand the issue
    keep it as separate as possible
    don't want to put them together
    separate issue -- have a boundary

    in the data send there is a flag that says transmit message again on failover to
    alternate
    undefined whether the application has the opportunity to respond to the failover
    indication to send messages before the retransmission of the retrieved messages

    implied: -- failover callback happens before you send the retrieved messages

    - fail-over convenience may be supplied by a separate protocol or within ASAP.
    - failover cannot be applicable for every application protocol.
    - on PU-PE : failover indication can go to the application
    3 possibilities:

    option 1:
    - ASAP can do SCTP based retrieval
    - indicate to ASAP if msg sent, set flag, transmit msg again on failover.

    option 2:
    - no automatic retrieval
    - SCTP retrieval is possible but not full(optional)

    option 3
    - no automatic retrieval
    - do application level acks(Rserpool based retrieval)

    option 4:
    - automatic retrieval with sendover flag and add application ack.

    application with application based ack should be supported by ASAP.

    Rough consensus for #4.

    Action items:
    1) Write up options 1-4 for retrieval and post it to the list -- Phil Conrad
    2) Phil and co-authors: Document iteration -- service and tcpmapping documents
    will both be updated to reflect the discussions
    This should be done sometime in June so we can read them before the July IETF
    meeting.

    ---------------------------------------------------------------------------------------------------


    2) ASAP

    There was a discussion on the organization of the ASAP document with the goal of
    making it easier to read and understand.

    Section 1 is PU-ENRP interactions: name resolution, server hunt
    Section 2 is PE-ENRP interactions: registration/deregistration, server hunt

    A) split section 1 and 2 into two separate documents
    B) reorganize current ASAP document into Section 1 followed by Section 2

    B is the rough consensus

    Action item:
    Randy Stewart will reorganize the ASAP document.

    business card (PECP- pool element control protocol)
    application ACK

    Should these be put in a separate document?

    Procedures how you do it what you do with it
    specify message format
    how you handle it on both sides

    Mapping document will determine this.

    Business card ==
    Pool handle
    Death wish list

    How business cards work:

    PU A -
    -
    PU B ---- PE 1 ----------- PE 2
    -
    PU C -

    CDMA example (see picture above):

    A, B and C are all using PE 1. If PE 1 dies, may be a requirement that they all
    need to failover to the same PE. Furthermore, they are synchronizing to PE 2. So
    PE 2 will also need to know which PE to contact if PE 1 dies. PE 1 will send
    business cards to PU A-C and to PE 2 so they can re-synch if PE 1 fails.

    PE Sends a business card to the PU that says when I die, here is the preferred
    list of PEs to contact in this order.
    Should business cards be sent in band or out of band? Can send a business card
    at any time. You can replace a business card with a new one.

    data transfer: done via the classical transport layer
    PECP transfer: use SCTP between the PU and PE, out-of-band information transfer
    or use the mapping if SCTP is not present.

    Bussiness card contains a last will which can be used if 2 PU can meet on the
    same PE element(normally, the rendezvous is NOT coordinated as ENRP will supply
    different lists to different requests.) a element of the wish list will first be
    checked with the cache. Wish list should be a option. No wish list means use
    ENRP, else use the info supplied in the bussiness card.

    The rendez vous point can only be determined by the PU/PE: needs also to
    distribute across the remaining PU/PE otherwise a single PU/PE will get all the
    traffic from the failed one. coupling can be done explicitly or implicitly.
    Application has to couple the 2 sessions(via ASAP primitive) and says PU clone
    this bussiness card from the PE.

    --------------------------------------------------------------------------------------------------------------


    3) ENRP

    How to synch up after the namerservers have been separated from each other?
    At present no mechanism exists to repair this.

    database can be check summed and send to other server. If the checksum doesn't
    match(ENRP servers are fully meshed and has the same state) then this must be
    repaired. (Audit) Same problem as with a accidental disjunct namespace.

    check my view with the view of the owner on the owner terms. Owner sends to
    other PE and the hash. If the hash doesn't match then PE must be inserted in the
    database or the hash is different and the owner is requested to send the info to
    the other

    duplicate PE identifiers and Server identifiers: the last will override the
    previous definition but that isn't a big problem. It is just a replacement of
    one with another. But if it is done on 2 different servers, then a resolution
    has to be made to "allocate" the identifier. identifier is unique within the
    pool.

    identifier can be made up of a part server id and PU id. use good random number
    generator. Easy one can be detected: on the same ENRP server, clashing
    identifier can be detected(reject the 2 announcement). Case for multiple servers
    is harder to resolve and will occur with a very low chance.

    How to mend two pieces of a split name space:

    ENRP servers get data from all other ENRP servers? Might be very chaotic.
    Everyone downloading information from everyone else.
    Form a spanning tree? This adds complexity.

    How to audit the namespace

    Use hash function or checksum. Only compare what I own. I send a PE ID and its
    hash.

    Audit will take care of the split network issue. Assuming that we have reliable
    transport, simple procedure that you have the same view or different view. If
    you have different view you have to exchange your data. Goal is: ENRP servers
    are fully meshed and all have the same view. If everything is fine that is what
    we have.

    2 lists
    List A agreement on these
    List B you have I don't OR I have but you don't

    Anyone on list B is added with a flag. Flag says you need to sanity check this
    guy. Fails or succeed.

    What about you can reach me and I can't reach you. Some ENRP servers will have
    different views from others. Network partition will have different views.
    Another case is we can talk ENRP A and B, but I can talk to PE X but you cannot.


    One possibility: Both agree that you can reach him and I can't.

    Should survive a network problem.
    A fact of life that routing protocols have problems. Unfortunate but not
    unexpected.

    Every time you do the audit that all this signaling is done because we don't
    agree. Don't refer any PU to Ken. Reachable/unreachable flag in the data base.

    If I ask Randy he is reachable if you ask Ken, he is not reachable. Who do I
    trust?
    No perfect solution, but if I'm an ENRP server. Say Ken is not available for
    anyone. That is one solution.

    He goes to the next one on the list, and that is perfectly fine.

    Only needs to find an element. Even one that can't contact Ken then no one
    should contact Ken.

    We want maximum survivability.

    To be a valid PE have to be reachable by all servers all the time?

    Consensus reached:
    Reintroduce the fathering solution as in the first ENRP drafts.
    Each PE is "owned" by a ENRP server
    TCP checksum the database. Only compare what I own. I send a PE ID and its hash.


    Action Items:

    1) Phil will work on this research problem of split namespace. Scope of Rserpool
    solution is for the Internet. This proposed Rserpool solution works in the
    current Internet Telcos and other server-client environment i.e. in the scope of
    the requirements document. Other solutions may need to be researched and
    proposed independently. Managing a split namespace is curtail for military
    environments. There will be two solutions -- military and IETF. As a research
    project Phil will investigate a solution based on military requirements.

    2) Qiaobing is going to put back the functionality in ENRP which requires each
    PE have a home ENRP server (fathering). This will allow for an authoritative
    answer on namespace auditing questions.

    3) hash or checksum the database. Only compare what I own. I send a PE ID and
    its hash. Randy writes this up for the mailing list.

    4) Phil Conrad - look at the common params doc and see if anything needs to be
    added.

    -------------------------------------------------------------------------------

    4) Architecture

    There was a question about pool element handle: should it be a zero terminated
    bytestring instead of a zero terminated ASCII string. Resolution: bytestring it
    is.
    same handle = same length + the same bytes in the string

    There was a discussion of various terms used in Rserpool.

    Pool element identifier: integer field in ENRP design (PEI)
    pool element handle local(comming from local ASAP call(PEH) must go away
    pool element handle parameter found in common parameters doc (goes over the
    wire)(PEHP)

    We need consistency of terms across all documents. Put all terms in one document
    for now. Before last call we can put them in the appropriate docs.

    Pool Element Handle:
    PEH : IP address + transport protocol?
    Answer from the ENRP server is
    all IP addrs + all the transport protocols -ASAP must filter locally to
    support the client (should ENRP filter or is it local to ASAP)

    There was a long debate on whether a PE that supports both TCP and SCTP should
    register once with an ENRP server OR the PE
    should register once for each separate transport. There are pos and cons to each
    approach. Qiaobing's analogy is that the PE is an animal with several legs. Each
    leg represents a different transport address. If the PE registers once, then if
    one leg of the animal is dead, you can infer that the whole animal might be dead
    and avoid that PE on failover. However, if the PE registers each leg separately,
    then you cannot tell which legs belong to the that animal. You will just try
    some other leg. In doing so, you might get the same PE (animal) but use a
    different transport. Chances are that it is also dead. A smarter strategy is to
    try another PE (animal) first and then if you exhaust all other PEs (animals),
    then go back and try another leg on the first animal. Animal might be ill, but
    not dead.

    Some related issues were:
    Is it possible to do a changeover from one transport layer to another transport
    layer?
    Are those different PEs or not?
    Does each PE support a single transport protocol or not?
    The present design implies one registration for each PE i.e. a PE has multiple
    transports.

    Case I = Multiple registrations (one registration for each transport address)
    for each PE

    Register PE + single transport = single leg of the same animal
    con: no loadsharing: load a single leg
    con: stuck with this solution
    con: no detection of the failed legs of the animal
    con: no detection of the legs belonging to the same animal.
    pro: simpler to understand, design could be harder

    Case II = Single registration for each PE

    Register PE + multiple transport: all legs of the animal
    pro: easier to detect the dead animal (one legs fails, high chance that others
    legs have also failed)
    con: more difficult for architecture
    con: more difficult to register (implementation dependant)
    pro: include the PE + single transport model
    con: clarify that you can fail over to yourself (is this possible?)
    ill : at least one leg failed
    dead: all legs failed
    if a leg fails, check first other animals before trying the others legs of the
    same animal.
    pro: the multiple reg include the single reg (is a optional restriction)
    loads a single animal

    Consensus was reached on Case II.

    registration of the different transport goes across the single SCTP
    association to ENRP server: is this possible?

    mention the functions that the different protocols should do.
    add bussinesscard and application ack to architecture.
    PE can send to PU and PU can send this to the PE after failover. some sort of
    fate sharing between the PE/servers

    We discussed the pros and cons of having a data AND control channel between PU
    and PE.

    PU/PE
    - there is always a data channel
    - in failover mode: data channel must use one of the transport mappings PU/PE
    ASAP msg should be muxed over same association/connection over the control
    channel.
    - in Name service mode: data channel is structured per application protocol.
    Rserpool imposes no restriction on this communication. If there is a need for
    ASAP PU/PE communication, a separate data channel may be opened, while a channel
    MUST used a mapped protocol or SCTP(XOR). This is not possible: there is no
    control channel.

    In failover mode the data channel MUST use one of the transport mappings
    PU-PE ASAP messages e.g.. application layer ACKs and business cards either MUST
    or SHOULD be multiplexed over the same association/connection

    business card must be there ahead of any user data -- Randy

    A MUST versus SHOULD discussion should be decided by the WG and held on the
    list.
    Randy will send a message to the list.

    name service mode:
    - should we do UDP based media using rendez-vous mechanism
    - bussinesscard needed in name service mode?
    - application ack possible?
    -do we need ASAP PU/PE communication?
    - if yes, do we use SCTP or the mapping protocol

    Action items:

    1) MUST versus SHOULD discussion on the list. PU-PE ASAP messages e.g..
    application layer ACKs and business cards either MUST or SHOULD be multiplexed
    over the same association/connection Randy will send a message to the list.

    2) Use the same terminology in all documents - All Put all terms in two
    documents:
    Common parameter definitions go to the common-param draft - Qiaobing Xie
    Terminology definitions go to the architecture draft - Michael Tuexen.

    3) Michael and Phill - write text for the following
    Describe set of Functional requirements PU-PE, PU-ENRP,
    Add to architecture last will and testament -- business card
    Application level ACK

    4) Michael Tuexen set up the site with Rserpool drafts www.sctp.de

    5) Randy: Clarify in the ASAP document this registration and failover mechanism
    (for Case II). Give the rationale. Detect that one leg is unreachable should
    avoid going back to that animal (PE) until you exhaust all the other animals
    (PEs).
    Michael: Same action item for the architecture

    Slides

    Rserpool Endpoint Name Resolution Protocol
    Aggregate Server Access Protocol
    Services Provided by RSerPool
    RSerPool TCP Mapping