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

---

From: Phillip Conrad <[email-masked]>
Date: Fri, 22 Nov 2002 03:37:22 -0500

At 04:37 PM 11/21/2002 -0600, Qiaobing Xie wrote:
>remember). 
...

You are not wrong: this is exactly correct.  

There are many issues that your note raises, and over the next few days/weeks we can deal with each of them, including the proper format or organization of the services draft, and the distinction between 
* descriptions of abstract services (e.g. Section 10 of RFC2960,and Section 4 of draft-ietf-rserpool-asap-05.txt,) and 
* API specifications (e.g. draft-ietf-tsvwg-sctpsocket-05.txt)

For now, though, I want to focus on just two issues that I need more clarity about before I can proceed in any "format".

Issue 1:  The term "transparent failover"
=====

You use the terms "transparent failover" and "semi transparent failover" in your description of the services you think RSerPool does provide or should provide.   I need to understand *precisely* what you mean by these terms, and precisely what the distinction is between them.   Perhaps you can also distinguish each of these cases from 'not-at-all transparent failover'.

I would suggest that the following statements about the
ASAP layer on a PU are likely to be non controversial (or minimally so):

* it can manage the detection of when a given PE1 fails
* it can manage the selection of a new server PE2, 
* it can pass a state cookie supplied by PE1 before it died, 
  to PE2 as part of the failover. 
* it can _sometimes_ (if using SCTP) do a rollover of _some_ 
  messages (the ones that were not acked) to the new PE2 
  (but can lose messages that were acked at PE1 but  
   and never delivered...  more on this in "issue two!")
* it can provides a failure indication to the application 
  (that it can use as a hook to do *non* transparent things
   that need to happen to facilitate the failover).

What I don't see is how to map that onto the notion of  "transparent failover".  

Transparent failover to me means: the application just keeps on sending data and receiving data, and everything works seamlessly, just as if the first PE1 had handled the entire transaction.    The application "need never know" that a handoff occurred.  But if some data messages get lost in the handoff,  how can that be called transparent failover? 

My conversation with Michael Tuexen earlier today was instructive.   He and I were having a mismatch in our understanding and our communication.   We eventually uncovered that the root case was that we had entirely different classes of applications in mind.  I would suggest that our different understandings of transparent failover and the need for features such as "application layer acks" may be due to the same root cause.

I suspect that for the class of applications you have in mind, transparent failover can be provided by the existing RSerPool architecture, and no new features are needed...  i.e. application level acks are not needed to support transparent failover for the class of applications you have in mind.

For the class of applications I have in mind, new features (e.g. application layer acks) are mostly decidedly needed if transparent failover (the way envision it) is to occur.

It may surprise you to learn that I am amenable to dropping my request for those features (since they can be built into the application that sits on top of RSerPool) if I can understand precisely how to describe the class of applications for which transparent failover IS possible given the current set of RSerPool features.   

My problem is that I don't know what this class of applications is.   I suspect a lot of other folks who drop by the RSerPool WG, reads our documents, and try to answer the question "what good is it?" are in the same boat. I don't doubt that such a class exists.. I just don't know how to characterize that class, or even how to describe a single instance of that class.    

This is where I need your help.    I need you to explain what "transparent failover" looks like in your world view, and provide some guidance for determining for some application X,  whether RSerPool can or cannot provide transparent failover and/or semi-transparent failover for X.    If we can come to some consensus on this world view... or at least as a first step outline clearly what the competing world views are so we can evaluate them as a working group ... we can make progress on explaining  these issues in the services draft.

Issue Two: 
========

> - un-acked data rollover from "dead" PE to "new" PE during a failover (from 

Your description of the service as rollover of "unacked data", only when SCTP is the underlying transport protocol,  is correct and precise.   

However, I am troubled by the text that is currently in the ASAP draft concerning this service:

The ASAP  data.send.primitive currently has the following option:

>ASAP_SEND_FAILOVER: 0x0001 Enables PE fail-over on this message. In case 
>where the first selected PE or the PE pointed to by the PE handle is found 
>unreachable, this option allows the senders ASAP endpoint to re-select an 
>alternate PE from the same pool if one exists, and silently re-send the 
>message to this newly selected endpoint. 

As Michael, Peter and I discussed earlier this afternoon, (and they seemed to indicate agreement), we need to be very careful to outline the limitations of this particular service.   
If the intent is to provide lossless rollover on PE failure, then this cannot be done solely using the SCTP retrieval mechanism.   (I now understand that this is, at least for some of the RSerPool designers, NOT the intent, but I will address that point separately in a moment.) 

Additional text is needed that provides a very clear warning that the rollover is "incomplete" or "best effort", in the sense that messages that are acked but not yet delivered may never have been received by the old PE (they were received by SCTP, but not by the PE, i.e. the application sitting on top of ASAP) and will also never be received by the new PE.

This perceived limitation is the motivation for the proposed ASAP buffering and application layer acks, which, if it were incorporated into the RSerPool framework, would permit transparent and lossless rollover of messages on PE failover.    

Michael originally tried to convince me (at least I think this is what he was trying to convince me of) that the feature is perfectly appropriate as it is (relying solely on SCTP retrieval,   with not ASAP buffering or app-level acks) because, he claimed, *any* kind of rollover is best effort: no solution exists for a lossless rollover.   

I did not agree, and I think that Michael eventually understood and accepted my argument (which I outline below.)    We came to understand in the course of the conversation that we originally reached different conclusions because we had different applications in mind (that is the common theme of this note, and underscores the value of developing an applicability statement with use cases as we move forward!)

One class of applications is those where loss is not tolerable, but duplicates are tolerable.  An example is a situational awareness application in military communication, where mobile assets periodically report their position, status, etc.  Since each report carries a timestamp, duplicates are not an issue, however we want to ensure that no message is lost.   

The term "idempotent" is sometimes used to describe such operations, because they can be repeated without any ill effects (see definition at http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?idempotent)

My claim is that for this class of applications, the application layer ack mechanism can provide for lossless transparent failover.  It cannot prevent the delivery of duplicate requests (this is related to the impossibility of a protocol to solve the "two-army problem" described in many networking texts, including, for example Tannenbaum), but for idempotent operations, this is not a problem.    

The meaning of PE sending and application layer ack in this case is the following: "Hello Mr. PU.    Whatever needed to happen as a result of this message X from the PU to the PE has already happened.  You no longer need to send message X to any other PE, even if I die right after sending this ack".    That "thing" that needed to happen as a result of message X is application specific; an example might be that the PE updates some global shared database and successfully  carrying out a commit protocol before returning the application layer ack, for example.

Once I explained that this was the class of applications I had in mind, Michael agreed that the application layer ack solution is not "broken"; it does the job for which it was designed.  There are nevertheless compelling  reasons to NOT include this feature in RSerPool, and it may surprise you to learn that after my conversation with Michael earlier today, I am not leaning towards NOT including it as an RSerPool feature.    However, the argument that persuaded me is not the one that "it is broken and can't do the job" because that is simply not true.    In a separate note, I'll go into what did persuade me to change my mind on this point.    I still believe the mechanism is sound and useful, but rather than building it into RSerPool, I seems better at this point to write it up a "use case" for the applicability statement (an informational RFC).   

A different class is applications where a certain degree of loss is tolerable, but duplication of messages is not tolerable.   This is the class of applications, as I understand it from him, that Michael has in mind for the SCTP-retrieval based implementation of the 
ASAP_SEND_FAILOVER option of the data.send primitive.  (I will omit an example, and invite Michael to fill in one if he sees fit.. I think he has one in mind from the sigtran domain.)   

In this case, though, we do not want ASAP to resent unacked data, but only unsent data.    RFC2960 specified separate services for receiving unacked and unsent data, so it should be possible to distinguish between the two, though the current ASAP draft does not make this distinction! (this is another open issue.)

It would be helpful (for the applicability draft, it nothing else) to describe one or more use cases highlighting  how the feature is useful, and why its limitations are not relevant in the applications for which it is intended.

I hope this is helpful, and I look forward to your reply.

Regards,
Phill

---

From: Phillip Conrad <[email-masked]>
Date: Fri, 22 Nov 2002 03:37:22 -0500

...

Issue Two: 
========

Regards,
Phill

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 25 Nov 2002 19:03:43 -0600

Hi, Phill,

Please see my comments in-line...

Phillip Conrad wrote:
....
> You use the terms "transparent failover" and "semi transparent failover" in your description of the services you think RSerPool does provide or should provide.   I need to understand *precisely* wh…

I've never had a precise definition on those terms and I'd like to leave those terms
imprecise. I guess what I always mean when I use "transparent failover" is: the upper
layer can get that feature with no or very little intervention, and "semi-transparent
failover" simply means that the upper layer may need to intervene a little bit for that to
happen. Of cause we assume the upper layer has decided the feature is good, useful, and
desirable. In other words, "transparent" here is more meant to describe the amount of
effort the upper layer needs to put up in order to use the feature, rather than describing
the quality of the failover service.

> Transparent failover to me means: the application just keeps on sending data and receiving data, and everything works seamlessly, just as if the first PE1 had handled the entire transaction.    The…

We used to have a term for what you are describing here. We called it "transaction
failover", meaning the integrity of the transaction is preserved during a failover (i.e.,
no re-ordering or loss of user data). We discussed about whether this should be provided
by RSERPOOL when we were working on the requirements and the consensus was (and I believe
still is) not to build this into RSERPOOL. The reason: it is not simple to build and many
applications do not need this.

The following text was in the early version of the requirement draft:

"Transaction failover is not provided by reliable server pooling.  If a
host 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 text was removed when we condensed the requirement draft for IESG, but I believe the
consensus is still there.

> It may surprise you to learn that I am amenable to dropping my request for those features (since they can be built into the application that sits on top of RSerPool) if I can understand precisely h…

This was exactly the reasoning behind our decision of not to guarantee "transaction
failover" in RSERPOOL, since for those apps that really need it, they can always build
that feature on top of RSERPOOL. On the other hand, if we build this into RSERPOOL, many
applications will end up paying the (heavy) cost for something they never ask for.

> This is where I need your help.    I need you to explain what "transparent failover" looks like in your world view, and provide some guidance for determining for some application X,  whether RSerPo…

Maybe it would help to explain the difference by resurrecting the term "transaction
failover". I.e., 

"transparent failover" - failing over from one PE to another with little
or no effort from the upper layer. But data integrity during failover is not guaranteed
and is just best-effort. RSERPOOL supports this.

"transaction failover" - failing over from one PE to another with guaranteed data
integrity (e.g., no dup, no re-ordering, no loss). RSERPOOL does not provide this. But the
app can build this on top of RSERPOOL.

> Your description of the service as rollover of "unacked data", only when SCTP is the underlying transport protocol,  is correct and precise.

Again, my definition on "unacked data" is best-effort-based, i.e., whatever is
retrievable.

> If the intent is to provide lossless rollover on PE failure, then this cannot be done solely using the SCTP retrieval mechanism.   (I now understand that this is, at least for some of the RSerPool…

No. The above cited primitive is a per-message behavior valid only "on this message" and
has nothing to do with retrieve-then-send of any other messages in the sequence. There is
no intention here to provide a lossless rollover of multiple messages. The envisioned
sequence of events looks like this:

 - sender app has been passing messages to ASAP layer happily and some messages 
   passed were marked with ASAP_SEND_FAILOVER while others not.
 - the ASAP layer has been happily sending these messages to PE1
 - Suddenly an unreachable notification on PE1 pops up from the transport layer
 - the ASAP attempts a *best-effort* retrieval on the local endpoint of the 
   connection to PE1 and gets some "unsent and/or unacked" msgs back
 - the ASAP finds the backup (PE2) and re-sends messages marked with 
   ASAP_SEND_FAILOVER to PE2 and notifies its upper layer about other
   messages.

As you can see, here we assume the app is more sophisticated than "loseless rollover" - it
actually is allowed to do a "selective rollover".

> In this case, though, we do not want ASAP to resent unacked data, but only unsent data.    RFC2960 specified separate services for receiving unacked and unsent data, so it should be possible to dis…

I think this level of fine control should really be left to the upper layer which
understands the nature of the messages. This works well with the simple best-effort ASAP
rollover - for messages that the app absolutely does not want to lose, the app will enable
ASAP best-effort rollover AND as a backup run its own timer and app-ack for those
messages; for messages that the app absolutely does not want to duplicate, the app should
run its own timer and app-ack AND turn off ASAP rollover for those messages.

> I hope this is helpful, and I look forward to your reply.

regards,
-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Mon, 25 Nov 2002 19:03:43 -0600

Hi, Phill,

Phillip Conrad wrote:
....

regards,
-Qiaobing

---

From: Phillip Conrad <[email-masked]>
Date: Tue, 26 Nov 2002 01:07:05 -0500

Qiaobing,
  You raise some interesting points.  Here is further discussion on three of those:

1) The definition of "transparent failover" 
=============================

Phill Conrad wrote (in part) in response to an inquiry by Qiaobing:
>> You use the terms "transparent failover" and "semi transparent failover" 
>>in your description of the services you think RSerPool does provide or 
>>should provide.   I need to understand *precisely* what you mean by these 
>>terms, and precisely what the distinction is between them.   Perhaps you can 
>>also distinguish each of these cases from 'not-at-all transparent failover'.

Qiaobing Xie replied (in part):
>I've never had a precise definition on those terms and I'd like to leave 
>those terms imprecise. 

I think you provide an adequately precise definition later in your email.  I propose we adopt that definition (see below.)    

If you prefer to leave the term "imprecise", then we should avoid using it when describing the service provided by RSerPool.    A primary goal of the service draft is to explain to potential users of RSerPool what they "get" when they build on top of RSerPool.    We should not use "imprecise" language when doing so.

Later in the same email, Qiaobing wrote: 
>Maybe it would help to explain the difference by resurrecting the term 
>"transaction failover". I.e., 
>
>"transaction failover" - failing over from one PE to another with guaranteed 
>data integrity (e.g., no dup, no re-ordering, no loss). RSERPOOL does not provide 
>this. But the app can build this on top of RSERPOOL.

Ok, this distinction is a good start.  I propose we build on these definitions provided by Qiaobing.

Note, that there is an "implied" definition of transparent failover in "Introduction" section to the ASAP draft: 

>While delivering the message, ASAP monitors the reachability of the selected 
>PE. If it is found unreachable, before notifying the sender of the failure, 
>ASAP can automatically select another PE (if one exists) under that pool and 
>attempt to deliver the message to that PE. In other words, ASAP is capable 
>of transparent fail-over amongst instances of a server pool. 

There are interesting consequences of this definition.  First it implies a particular sequence of operations: namely, that the failover will happen, and that best-effort failover (retransmissions) of messages marked with ASAP_SEND_FAILOVER happens *before* a notification is sent to the upper layer about the failure of the first PE.

Is that the correct interpretation?  

2) The ASAP_SEND_FAILOVER option
=============================

Qiaobing wrote: 
>The  envisioned sequence of events looks like this:
>
>As you can see, here we assume the app is more sophisticated than "loseless 
>rollover" - it actually is allowed to do a "selective rollover".

Ok. I would suggest that the ASAP_SEND_FAILOVER text be modified as follows. 
This is along the lines of what I discussed with Michael and Peter in Atlanta; though
we did not at that time discuss specific text, they agreed in principle that we needed
to clarify the limitations of the existing "SCTP-retrieval" based failover.

The changed text is marked by "*" in the first column.

 ASAP_SEND_FAILOVER: 0x0001 Enables PE fail-over on this message.  In
       case where the first selected PE or the PE pointed to by the PE
*      handle is found unreachable, the sender's ASAP
*      endpoint MAY [or SHOULD?] re-select an alternate PE from the
       same pool if one exists, and silently re-send the message to this 
       newly selected endpoint.  

*      Note that this is a best-effort service.  Applications should be 
*      aware that messages can be lost during the failover process, even
*      if the underlying transport supports retrieval of unacknowledged 
*      data (e.g. SCTP) (Example: messages acknowledged 
*      by the SCTP layer at a PE, but not yet read by the PE when 
*      a PE failure occurs.) In the case where the underlying transport
*      does not support such retrieval (e.g. TCP), any data already
*      submitted by ASAP to the transport layer MAY be lost upon failover.

The first change doesn't change the meaning of the text, but it rephrases it 
to use the "capital-MAY" instead of the weaker lowercase "allows" to 
highlight for the reader that the re-sending is not required behavior.   

We might even strengthen the text by changing the MAY to a SHOULD, though we
can only do this because of the provisions in the added paragraph that spell out
what happens when "retrieval" is not available, as in TCP.

The additional text helps to emphasize the idea that the service is *best-effort* (a point also highlighted in Qiaobing's response with *'s), and that transports other than SCTP might not support it.

3) Use cases for "lossy" failover
=======================

Phill Conrad wrote, in part...
>> One class of applications is those where loss is not tolerable, but duplicates 
>> are tolerable.
...
>> A different class is applications where a certain degree of loss is tolerable
>> but duplication of messages is not tolerable...
....

Qiaobing responded (in part):

>understands the nature of the messages. This works well with the simple 
>best-effort ASAP rollover - for messages that the app absolutely does not 
>want to lose, the app will enable
>ASAP best-effort rollover AND as a backup run its own timer and app-ack for 
>those messages

There is something here I don't get.  In this example, you state that the app is running its 
own timer and doing its own app-layer acks.  So why on earth would it turn 
on the best-effort rollover, resulting in packets that are guaranteed to be 
duplicates?  If the application is already doing the rollover itself, It seems to me more appropriate in this circumstance to turn  off the RSerPool rollover, to avoid redundant bits on the wire.

>or messages that the app absolutely does not want to duplicate, 
>the app should

So here's another case where it makes sense to turn the ASAP rollover off.   

What I would still like to see is the case where it makes sense to turn it ON.   What is the application where "best-effort" rollover makes sense?

In the absence of such an explanation, it seems just as prudent to leave out this feature as it does to leave out application layer acks.  After all why burden applications that don't need the feature, when applications that do could build the feature itself on top of RSerPool (if provided an API with enough pass-through access to the transport layer, and the appropriate notifications?)

Of course, I am setting up a strawman here..  I would imagine that you will argue for the inclusion of this feature because you feel that it is generally very useful, and provides an adequate solution for a reasonably large class of important applications.   

OK... so tell me: what are these applications?   Can you just give me at least *one* example, or point to one that is already in the existing drafts?     Neither the current examples in the architecture draft, nor the example in the ASAP draft give me any clear picture of an application where the "best-effort" failover is useful, given its limitations.

As I said before, and I will repeat (since my question remains unanswered): 

It would be helpful (for the applicability draft, it nothing else) to 
describe one or more use cases highlighting  how the feature is useful, and 
why its limitations are not relevant in the applications for which it is 
intended.

Best regards,
Phill

---

From: Phillip Conrad <[email-masked]>
Date: Tue, 26 Nov 2002 01:07:05 -0500

Qiaobing,

...
....

Best regards,
Phill

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 26 Nov 2002 17:24:16 -0600

Hi, Phill,

> 1) The definition of "transparent failover"

By being "imprecise", I basically meant to indicate the fact that, similar to other
documents in IETF, many parts of the RSERPOOL drafts were written, and should therefore be
read, as "descriptive" text, rather than "definitive" text (we make important points
"definitive" by using those capital key words). Of cause, your careful reading and
feedback will surely enhance the clarity and correctness of the text no matter it's of
"descriptive" or "definitive" nature.

> >or no effort from the upper layer. But data integrity during failover is not
> >guaranteed and is just best-effort. RSERPOOL supports this.
> >

Ok.

> Is that the correct interpretation?

I think you are close. This is an example of the "descriptive" text. Here, "...before
notifying..." does not necessarily mean a definitive order of two ASAP actions. It rather
means: before rushing to notify the app layer, ASAP needs to check the flag on the message
first, since it may not need to notify the app after all (e.g., the app may have marked
the message as "feel free to roll it over and don't bother to notify me in such an
event").

But if we are talking about an API document, the text above surely would need to be more
definitive, so as to show the reader how, when, with what syntax, the app should mark and
get notified of those events.

> > - sender app has been passing messages to ASAP layer happily and some
> >   messages passed were marked with ASAP_SEND_FAILOVER while others not.

SHOULD is better. This is like the app is asking ASAP to perform this rollover treatment
to *this message*, therefore ASAP should try its best to do so.

>        same pool if one exists, and silently re-send the message to this

maybe no need to preclude the app getting a notice at the same time, i.e., "feel free to
roll it over, but please let me know when that happens"

> *      submitted by ASAP to the transport layer MAY be lost upon failover.

This text is good. But maybe it should be moved to a diff location since this particular
paragraph is talking about the treatment of a single message.

> There is something here I don't get.  In this example, you state that the app 
> is running its own timer and doing its own app-layer acks.  So why on earth would 
> it turn on the best-effort rollover, resulting in packets that are guaranteed 
> to be duplicates?  

The answer is again in the "best-effort" design concept - the majority of the messages
that got rolled over in ASAP layer will not be lost, thus the app rtx timer will only kick
in occasionally for the small percentage of messages that actually get lost after a
rollover. 

Say, when a PE dies, there is a 1% chance that a message in transit might be lost during
the rollover (e.g., at the moment of failure the msg may have been acked at the SCTP layer
but is waiting to be processed in the app-layer queue of the now-dead receiver. This
message will be lost during the ensuing rollover since it will not be retrieved nor will
it be re-sent by ASAP at the sender side). But the other 99% of message in transit will be
rolled over successfully and received and acked by the new PE and their rtx timer will
never fire.

In comparison, if you turn off the best-effort rollover in ASAP, 100% of your messages in
transit at the moment of the failover will trigger a time-out and need to be re-sent by
the app.

I don't understand why you say "guaranteed to be duplicates". Do you mean "there MAY be
duplicates"?

> If the application is already doing the rollover itself, 

No. The app is NOT doing *rollover*. It is only doing *timer-based retransmission*. The
difference btw the two is huge.

> It seems to me more 
> appropriate in this circumstance to turn  off the RSerPool rollover, to avoid 
> redundant bits on the wire.

ditto.

> So here's another case where it makes sense to turn the ASAP rollover off.

That's why the flag is designed to be on a per message basis.

> What I would still like to see is the case where it makes sense to turn it ON.   What is the application where "best-effort" rollover makes sense?

ditto.

> OK... so tell me: what are these applications?   Can you just give me at least *one* example, or point to one that is already in the existing drafts?     Neither the current examples in the archite…

The methodology of achieving lossless communications by combining best-effort lower layer
with a backup upper layer rtx timer is widely used and deployed across the industry.
RSERPOOL is not inventing anything here, it only applies the same methodology to achieve
lossless rollover. Arguably, this is the most cost effective way of achieving lossless
rollover, comparing to the two alternatives you've provided - 1) to remove rollover from
ASAP and let app do its own rollover, or 2) build a completely lossless rollover mechanism
inside ASAP.

> why its limitations are not relevant in the applications for which it is

I hope the above explanation can help.

regards,
-Qiaobing

---

From: Qiaobing Xie <[email-masked]>
Date: Tue, 26 Nov 2002 17:24:16 -0600

Hi, Phill,

Ok.

ditto.

ditto.

regards,
-Qiaobing