Subject: [Rserpool] a general comment to the service draft

From: Qiaobing Xie <[email-masked]>
Date: Thu, 21 Nov 2002 16:37:20 -0600

Hi, all,

At the face-to-face meetings we had in the past few days, a very good and important point
was raised multiple times - the application people wants to know exactly "what
features/services can RSERPOOL bring us?" After reading the service draft, we still feel
the answer for this simple question is not spelled out clearly in the draft. We may be
wrong but our understanding is that answering this question was the original motivation of
creating such a informational service document (per John Loughney's suggestion we
remember). But the current structure of the service draft seems to be more towards an API
document.

Here we give an outline of what we think the answer to that question should look like:

========================
Features an RSERPOOL application can expect:

Common features (available regardless what user data transport the app may use):
 - low-cost IP clustering (without need for special h/w or OS support)
 - load sharing with various polices, including user definable ones
 - no load balancer necesarry (i.e., peer-to-peer arch)
 - dynamic scalability 
   * adding PE dynamically
   * removing PE dynamically
 - distributed namespace (i.e., no single point of failure)

Additional features if application uses SCTP to transport data:
 - fast transparent session failover from an unreachable PE to a "live" 
   alternate PE in the pool
 - un-acked data rollover from "dead" PE to "new" PE during a failover (from SCTP) *
 - other transport features from SCTP (fast unreachability detections, multi-homing,
   multi-stream, un-ordered, heartbeat, etc.)

Additional features if application uses TCP to transport data:
 - transparent session failover from an unreachable PE to a "live" alternate PE(?)
   (this could be very slow or even unusable since TCP unreachability detection 
   may take up to a few min)

 [Note 1: a wrapper/mapping/adaptor layer can be added on top of TCP to improve
  the failover performance and add some SCTP-like features --> TCP mapping draft]

Additional features if application uses UDP to transport data:
 - none

 [Note 2: semi-transparent failover can be provided if an appl level failover trigger
  is made available to ASAP. This is easy to have with RTP, MGCP, MEGACO, etc, on top]

regards,
-Qiaobing and Michael
_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool