[Rserpool] Rserpool Minutes of IETF #54

[[e-mail]]

As always, comments to the list.

-- maureen

Minutes of Rserpool 
IETF #54 Japan  Monday, July 15, 2002  1530-1730
Co-chairs:
       Lyndon Ong, [e-mail]
       Maureen Stillman, [e-mail]

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".


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