Subject: Re: I've been wondering if

From: Manoj Dhooria <[email-masked]>
Date: Thu, 1 Feb 2001 14:19:15 +0530

Some education for me on SCTP here, Randall. Thank you for that. But ...

For me, SCTP is used only to run ASAP & ENRP. That is ok in so far as it
lets my client applications locate the list of servers that comprise the
pool. SCTP doesn't help me a bit the moment my real application takes charge
& starts talking to my services (returned as PE list by previous ASAP calls
over SCTP) using HTTP (over TCP).

-----Original Message-----
From: Remote Server Spooling
[mailto:[email-masked]]On Behalf Of Randall R.
Stewart
Sent: Thursday, February 01, 2001 1:35 AM
To: [email-masked]
Subject: Re: I've been wondering if

Manoj Dhooria wrote:
>
> RSerPool gives me only server redundancy, or ISP redundancy too. Two are
> really different sides of the same coin. I am kind of being forced to
> introduce ISP redundancy into my server - essentially, two IP addresses
that
> access the SAME IDENTICAL SERVER PROCESS & ITS STATE ON THE SAME PHYSICAL
> MACHINE ON SERVER LAN. Essentially saying a pool element PE1 is accessible
> via two separate IP addresses - IP1 & IP2.
>
> The reason I need this is as follows. I have a pre-production server
product
> running on my Bombay facilities, & corresponding pre-production clients on
> the notebooks of sales staff - for demonstrations to early partners. I
have
> two independent ISPs serving my Bombay facilities - both have a tendency
to
> blank out every now and then. So I have two URLs which sales staff
manually
> switch when one doesn't work - something a little embarrassing in front of
a
> potential customer. Since both URLs essentially reach the same physical
> server process, I can make their life somewhat easier if my client
> automatically switches as necessary.

Here is why you want SCTP and why we specify this as the
transport of RserPool.  SCTP allows the transport association
to span both IP addresses. So if one of the ISP's fail, the
SCTP association does not but automatically retransmits the
request (or whatever) to the alternate address.

The fault tolerance issue is really two fold, one layer is
server redundancy... i.e. what happens when an individual
PE dies. The other is link redundancy, i.e. what happens when
I accidently kill one of the enet wires connecting my server?

The link layer SCTP handles
The PE layer ASAP handles..

The two together form a very powerful mechanism that solves
the problem...

R
--
Randall R. Stewart
[email-masked] or [email-masked]
815-342-5222 (cell) 815-477-2127 (work)

---

From: "Randall R. Stewart" <[email-masked]>
Date: Thu, 1 Feb 2001 05:12:48 -0600

Hmm:

Well if you continue to use TCP thats your
choice, but the good news for you is that ASAP
will establish an association between the PU and PE.
This means that SCTP will do the HeartBeating and report
a problem when an interface goes down OR the endpoint
dies. Now this does not help you much in your case
where you are connected on the interface that
goes down... Your app might be able to use events
coming up or something....

I think eventually you will see an option to run
HTTP over SCTP that will really fix this problem for
you though :) It was talked about by Vern Paxson
quite some time ago and I think in the end it will happen.
How far away the "end" is, I don't know :)

R

---

From: Manoj Dhooria <[email-masked]>
Date: Thu, 1 Feb 2001 18:43:30 +0530

Could letting me "include" an entire pool as a member of another pool help
solve the problem *today*? Here is an example case.

I have 3 servers - A, B, & C running the same service. A & B are in Bombay,
are connected to external world via different ISPs, & actually reach the
same server process on my Bombay LAN (so I can do failover when one of these
ISPs dies). Let's say C is physically located in a different city - say
Pune, is reached via a local ISP, & of course can not access my Bombay
process (so no failover between Bombay/Pune servers). I now setup my pools
like this:

  Pool P1: name=IdenticalBombayServers;
           elements="IP-addr-of-A IP-addr-of-B";
           IdenticalServers=true // User defined attribute (not part of
ASAP/ENRP)

  Pool P2: name=MyUserVisibleService;
           elements="Pool->IdenticalBombayServers IP-addr-of-C"

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Thursday, February 01, 2001 4:43 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: I've been wondering if

Hmm:

R

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 1 Feb 2001 13:38:17 -0800

that
product
have
to
manually
a
> automatically switches as necessary.

I'd note that it is also possible to use a loopback address.
That is, an address that is not tied to a particular
interface. That way if an interface dies, the transport
connection can be rerouted over another interface. This
is routinely done with TCP today (BGP peering is typically
done this way).

Presumably if you have more than one ISP, you are also
advertising your prefix to both. So within the limits of
BGP convergence, you could keep the transport connection up.