Subject: FW: Redundant MG's

From: Lisa Amberger <[email-masked]>
Date: Thu, 25 Jan 2001 14:02:41 -0500

Section 11.4 "Failure of an MG" in RFC 3015 states that:

   Allowing the MGC to send duplicate messages to both MGs accommodates
   pairs of MGs that are capable of redundant failover of one of the
   MGs.  Only the Working MG shall accept or reject transactions.
Given one or more redundant MG's. When an MGC sends messages to the primary
MG and one or more secondary MG's.
How is retransmission handled?
A) Each time that the message is retransmitted to the primary MG, it is also
retransmitted to the secondary MG's.
B) Retransmission to the primary MG and secondary MG's is handled
independently. (The SRTT time will be used for retransmissions to the
primary MG. The default RTT will be used for retransmission to the secondary
MG's)
C) Messages are only retransmitted to the primary MG.

---

From: Tom Taylor <[email-masked]>
Date: Mon, 29 Jan 2001 09:36:27 -0500

We need to distinguish between retransmissions triggered by application-level timers when reliable transport is being used and
retransmissions when UDP/ALF is being used.  In the latter case, messages should be acknowledged by the inactive MG(s) even if
they are not being accepted or rejected.  The MGC should handle retransmissions to each MG independently, since the messages
may be taking different routes and thus be subject to different loss conditions.

Tom Taylor

---

From: Chanchal Hassija <[email-masked]>
Date: Tue, 30 Jan 2001 11:03:06 +0530

Hello,

I am not in full agreement with the text given in the protocol....

>   MGs.  Only the Working MG shall accept or reject transactions.

What's the use of sending duplicate transactions to standby MG when it is not
doing anything with those transactions ?

Transactions should be sent to the MG which creates association with MGC and
after switchover, transactions should be sent to the newly active MG.

Also, when we talk about duplicate transactions from MGC end, are these
transactions going on two different associations ?

Thanks for your time ....
Chan....

Tom Taylor <[email-masked]> on 01/29/2001 08:06:27 PM

Please respond to Tom Taylor <[email-masked]>

To:   [email-masked]
cc:    (bcc: Chanchal Hassija/HSS)

Subject:  Re: FW: Redundant MG's

We need to distinguish between retransmissions triggered by application-level
timers when reliable transport is being used and
retransmissions when UDP/ALF is being used.  In the latter case, messages should
be acknowledged by the inactive MG(s) even if
they are not being accepted or rejected.  The MGC should handle retransmissions
to each MG independently, since the messages
may be taking different routes and thus be subject to different loss conditions.

Tom Taylor

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 30 Jan 2001 10:46:35 -0500

First point: that the redundant MG cannot accept/reject transactions simply
means that it does not send transaction responses back to the MGC.  It can
still update internal state, allowing it to take over immediately if the
other MG fails.  I am still bothered by the transport issue: the arrangement
won't work with UDP/ALF unless empty messages are sent back to the MGC to
acknowledge received messages.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, January 30, 2001 12:33 AM
> To: [email-masked]; Taylor, Tom-PT
> [NORSE:B901:EXCH]

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 30 Jan 2001 11:10:48 -0500

I agree with your concern about UDP.

Either we deprecate the whole idea, or we have to add words in the
Implementors Guide.
First of all, how does the MGC know about the redundant MG?
    We need a ServiceChange that registers you as a secondary for (some
number of?)
        primaries
    Then we need an "ack" for transactions.  Probably just a
Reply=TransactionId.

Brian

-----Original Message-----
From: Tom-PT Taylor [mailto:[email-masked]]
Sent: Tuesday, January 30, 2001 10:47 AM
To: [email-masked]
Subject: Re: FW: Redundant MG's

> From: [email-masked] [ mailto:[email-masked]
<mailto:[email-masked]> ]

---

From: Tom-PT Taylor <[email-masked]>
Date: Tue, 30 Jan 2001 21:00:12 -0500

The concept is implementable: configure knowledge of redundancy in the MGC
and use reliable transport.  Hence I don't think we should deprecate the
existing text, but in v2 we should fix it.

 -----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, January 30, 2001 11:11 AM
To: Taylor, Tom-PT [NORSE:B901:EXCH]; [email-masked]
Subject: RE: FW: Redundant MG's

Brian

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 31 Jan 2001 08:04:04 -0500

Add to the text that says :
 Allowing the MGC to send duplicate messages to both MGs accommodates
 pairs of MGs that are capable of redundant failover of one of the
 MGs.  Only the Working MG shall accept or reject transactions.

Something like:
Redundant failover MGs with the current protocol definition
requires a reliable transport, and knowledge in the MGC of the
redundancy at the MG.

Brian

> From: Christian Groves [mailto:[email-masked]]
> Sent: Tuesday, January 30, 2001 9:58 PM
> To: Rosen, Brian
> Cc: [email-masked]
> G'Day Brian,
> Exactly what text are you referring to?
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > I don't have any problem with that as long as something
> like what you
> > just said is in the implementor's guide.
> >
> > Brian
> >
> > From: Tom-PT Taylor
> > Sent: 1/30/01 9:00 PM
> > The concept is implementable: configure knowledge of
> redundancy in the
> > MGC and use reliable transport.  Hence I don't think we
> should deprecate
> > the existing text, but in v2 we should fix it.
> >
> > First point: that the redundant MG cannot accept/reject transactions
> > simply means that it does not send transaction responses back to the
> > MGC.  It can still update internal state, allowing it to take over
> > immediately if the other MG fails.  I am still bothered by
> the transport
> > issue: the arrangement won't work with UDP/ALF unless empty
> messages are
> > sent back to the MGC to acknowledge received messages.
> >