Rspool BOF  Tuesday, August 01, 2000

Co-Chairs: Lyndon Ong (long@nortelnetworks.com), Maureen Stillman (maureen.stillman@nokia.com)

Reported by Maureen Stillman

The RSPool BOF was held on Tuesday, August 1, 2000 from 5-6PM.  Approximately 90 people attended this first BOF. Lyndon Ong from Nortel Networks and Maureen Stillman from Nokia chaired the meeting. An RSPool mailing list had been started one month prior to the BOF to gauge interest and begin discussions. A draft charter had been produced on this mailing list.

Lyndon Ong introduced the BOF. John Loughney of Nokia presented a discussion of applications in the signaling world, especially for mobile networks.

Next, Randy Stewart of Cisco and Qiaobing Xie of Motorola presented a proposed set of generic requirements based on their joint Internet draft: Draft-xie-stewart-ddp-01.txt. They identified two areas of work, the client/server binding and the reliability management.

This was followed by a lively discussion of requirements for reliable server pooling and further questions concerning the speaker's talks. This input will be collected, integrated into the draft charter and posted to the mailing list for further comment. Our goal is to complete the draft charter by the end of August. This draft will be submitted to the IESG for review and comment. Subsequently, the IESG will make a determination concerning the formation of an RSPool working group. The technical advisor for this group is Ned Freed, Area director of Applications.

Q=Query, R=Response and C=Comment

Q: How can you not standardize on the state sharing mechanism?
R: This is out of scope of the WG; hooks will be provided where possible to assist applications in implementing their solutions (e.g. ability to send checkpoint information to all of your peer names).
Q: How do you decide whom to failover to?
R: This is based on policy for the server sets.
Q: What is the overlap with DNS, if any?
R: Unlike DNS, we need to monitor the health of the servers, have much faster addition and subtraction of server names and collect fault reports from clients. DNS doesn't do this. DNS may be interworked with for scaling up.
Q: Will there be a common rspooling mechanism for each transport layer, e.g. SCTP has multi-homing, TCP does not.
R: The goal would be a single protocol.
C: We need a separation of the mechanisms into namespace usage and name-space management.
C: Charter/scope should be more specific on fail-over times.  Seconds to fail over is a joke for some applications

Three key questions:
How much time does it take to distribute application checkpoint information?
How much time does it take to fail over?
How does all this relate to caching?
(Note that if you are caching, you don't have to do another namespace lookup)

Q: Will the group have some sort of stringent performance/timing requirements or we don't care?
R: Any requirements should include a reasonable set of values. Specify objectives and milestones; these should NOT be just for the telephony space!
Q: Once client/server binding is established, does the client go to the same server again and again or just load shared among servers? What about the two different requirements?
R: We need to support both.