Subject: Re: [Megaco] Open Issue 2: Replies to requests from failed MGC

From: Terry L Anderson <[email-masked]>
Date: Fri, 18 Jan 2002 14:28:09 -0500

Here's a second open issue.  There were only 5 messages in this thread back in
August but then it died without a resolution.  Yet it seems IMHO an important issue
on which the current H.248 is inconsistent.

The issue is whether replies to requests from a failed MGC are sent to a secondary
MGC or are sent to the failed MGC (in spite of likely failure) and whether replies
go to the original MGC after a handoff or be sent to the new MGC.  See the original
analysis of the current statements in H.248 near the bottom.  The conflict is
between 9.1 and statements in D.1 and D.1.5 (that apply only to IP) with that
statement in 11.5.

As explained below, the email archives show a previous discussion of the issue in
Jan 2000 with the final statements suggesting 11.5 be changed and Tom seems to come
to that conclusion in his reply below.

Admitted the rule that the reply should be sent to the MGC that is believed to have
failed makes little sense, but I think that that real issues are:

1. should the protocol use a simple rule that replies ALWAYS go the the addr/port
from which the request came, or have exceptions?

2. should the protocol assume that a Secondary MGC shares state with the Primary? or
should that only be one possible design.

I argued for the simple rule to apply even to this case, since if Secondary and
Primary do NOT share state, sending the reply to the secondary will do no good (it
knows nothing about the request).

If we want to make the operation of pair (Primary and Secondary) that share state
more efficient, perhaps we need to negotiate between the two cases at Registration.

To summarize:
Option #1:
    Change 11.5 to agree with 9.1 and D.1 and the "simple rule" (I actually proposed
text in my original message near the bottom).

Option #2:
    Introduce a way for MGC to specify in Registration response, which of two
options to follow, (1) send all responses to sender, (2) send all responses to
active MGC (after handoff or failover).  MGC would chose based on whether it shared
state with its Secondary.  Change 11.5 (and 9.1, D.1) to use this information to
choose between two behaviors on where to send responses.  This seems like a
significant change to try to introduce into V1 through the IG.  If option #2 is
preferred, perhaps we need to do Option #1 in V1 and introduce Option #2 in H.248v2.

Tom Taylor wrote:

> When we did that section 11.5 stuff, it was certainly in my mind that (assuming shared MGC state), the new MGC would take over from
> the old at a certain point, including closing out old transactions.  I can see the catch: this makes message validation at the MG really
> messy.  If there was no shared state, the old transactions would be cleared by resending them to the new MGC.  Maybe this is the
> appropriate procedure in all cases and 11.5 should be changed.
>

Christian Groves wrote:

> G'Day Terry,
>
> Please see comments below [CHG].
>
> Christian
>
> Terry L Anderson wrote:
> >
> > Christian Groves wrote:
> >
> > > G'Day Terry,
> > >
> > > A few points on this.
> > >
> > > o I think D.1.5 needs to be updated ie.
> > >
> > > "In order to account for the possibility of an undetected or in-progress
> > > "failover", we modify the classic algorithm so that if the Media Gateway
> > > receives a valid ServiceChange message announcing a failover".
> > >
> > > Shouldn't this state "handoff" instead of "failover" as handoff is sent
> > > from the MGC to the MG?
> >
> > You are right.  Hadn't noticed this, but MG should never receive ServiceChange
> > message announcing a failover".
> >
> > > o Given that the MGCs are maintaining state in a "handoff" situation I
> > > find it strange that replies from the MG are sent to the "old MGC"
> > > whilst the "new MGC" must send replies to the MG. If the "old MGC" has
> > > died and can't actually receive the command reply how will the "new MGC"
> > > know that a command has been executed?
> >
> > I thought we had agreed that replies would always be sent to source address of
> > request (which would be "old MGC" in this case):
> > - to keep simple consistent rule
> > - because entity at another addr may not know about request
> > - match rule for handoff
>
> [CHG] I'd like to keep things simple also but if simple means broken
> then I'd rather something a little more complicated. I'm confused about
> your comment on handoff because the text was talking about the handoff
> case. Also the comment about the entity at another addr not knowing
> about the request this is also true for the new entity sending a reply.
> So we have an inconsistent rule, the new MGC can't know to receive a
> reply but can know to send one.
>
> >
> > This means of course that the in the event of an MGC failure, these
> > transactions will fail (replies sent to old MGC will not be processed), but
> > unless the new MGC shares transaction state with old the replies will be
> > ignored anyway if sent to new MGC.  If these transactions fail, the new MGC
> > should (through shared state or audit) should issue new transactions to
> > accomplish the still needed task and these will succeed.
>
> [CHG] I think the real question we need to ask is do the MGCs share
> state? If so then the new MGC shall be able to operate as the old one.
> If not then the new MGC can't know anything. ie. it can't send or
> receive replys from previous commands.
>
> >
> > For handoff the rule works since the old MGC can send/accept replies for
> > outstanding transactions before going out of service.
>
> [CHG] Yes but what happen if the MG sends a reply to a command received
> before the service change after the acceptance of the service change?
> The MGC may have already gone out of service.
>
> >
> > Basically there are two stategies:
> > 1) tie transactions to a specific MGC: all pending transactions between MG and
> > old MGC (either direction) will complete with old MGC during a handoff and
> > will fail during a failover.  MG may reissue new transactions with same
> > actions for those that fail after registration with new MGC.  MGC may reissue
> > new transactions with same actions for those that fail after determining they
> > are still needed by shared state or audit.
> >
> > 2) tie transactions to collections of MGCs (primary and all secondaries): all
> > pending transactions between MG and old MGC will be continued (if possible)
> > with new MGC.  MG should send replies to new MGC and expect replies to its
> > transactions from new MGC.
> >
> > Some current statements in H.248 seem to assume the first and others the
> > second.  I dislike #2 because:
> > a) it will only work if MGCs share transaction state.  Elsewhere H.248 allows
> > but does not require MGCs to share state with its secondaries.  Although, I
> > admit that all that will happen if they do not share state is that all pending
> > transactions will fail, which is the same that will happen in #1 for
> > failover.  #1, though allows pending transactions during handoff to succeed.
> >
> > b) it breaks our "all replies to source address" rule.  It requires that in
> > this case we send replies to an address in the ServiceChange message or in
> > provisioned secondary MGC list.  I believe that this breaks one of the hacks
> > for working through NAT devices.
> >
> > #1 seemed to be the conclusion of all mail threads I found (3 or 4 since Jan
> > 2000).
>
> [CHG] Perhaps what we need is option of both and describe the behaviour.
> As I mentioned above it comes down to whether you support state sharing
> or not.
> I'm not particularly concerned about a general rule for NATs because its
> a transport specific behaviour see my comment below.
>
> >
> > > o Annex D is purely about IP transports, so I don't think we should take
> > > it as a general guide to how the protocol works. We put transports in
> > > Annexes so that we could have a common core protocol and use the Annexes
> > > to tailor some procedures.
> >
> > I agree.  Perhaps, details describing this issue should be removed, allowing
> > such to be stated in 7.2.8 and 11.5.  This also helps ensure that we treat TCP
> > equally with UDP.  D.1.5 only applies to UDP but issues of where replies go
> > should be same for both.
> >
> > > o Perhaps an exception to the rule is necessary. If you receive a
> > > command from a valid, secure MGC telling you to you a new address then
> > > what is the problem in using it?
> >
> > Of course you will use it for new transactions, the question is whether that
> > new MGC can handle pending transactions (send or receive replies).
> >
> > > Cheers, Christian
> > >
> > > Terry L Anderson wrote:
> > > >
> > > > I hate to open this again.  I believe we have settled this but the IG
> > > > does not seem to have a change.
> > > >
> > > > The issue is whether replies to requests from a failed MGC are sent to a
> > > > secondary MGC or are sent to the failed MGC (in spite of likely
> > > > failure).
> > > >
> > > > We have a number of statements (section 9.1, D.1, D.1.5) all of which
> > > > say that replies must be sent to the address and port from which the
> > > > request was sent.  I believe we are in agreement that this is a rule
> > > > without exception.  But 11.5 pretty clearly contradicts this.
> > > >     "Accordingly, commands in progress continue, TRANSACTION REPLIES ARE
> > > > SENT TO THE NEW MGC (after a new control association is established),
> > > > and the ..."
> > > >
> > > > The context does NOT sound like these replies are only replies to new
> > > > requests (which would hardly need to be stated.  And so this seems to
> > > > contradict the general principle or suggest an exception to the
> > > > otherwise simple rule.  However, D.1.5 seems to be talking about exactly
> > > > this same case and follows the general rule.
> > > >
> > > > This discrepancy appears to have been noticed as early as Jan 20, 2000
> > > > by Shalini Philip and Brian Rosen's reply of Jan 21, 2000 suggested 11.5
> > > > needed to be changed.  I see the same point raised a few more times in
> > > > the archives.  And replies always seem to support the general rule.  I
> > > > find no support for the 11.5 wording.  But I can find no correction to
> > > > this in the IG (if its there could someone point out the item number).
> > > >
> > > > Are we in agreement that this wording is in error and should be changed
> > > > to something like:
> > > >
> > > > "Accordingly, commands in progress continue and replies to all commands
> > > > from the original MGC must be sent to source address and port from which
> > > > they were sent (even if they are likely to fail). The MG should expect
> > > > outstanding transaction replies from the new MGC."
> > > >
> > > > Do we still agree with the last sentence (from the last clause of the
> > > > original)?  Should the new MGC (if it can) reply to transactions sent to
> > > > the failed MGC (this, of course, will  happen only if the MGCs had
> > > > shared state)?  These replies can still be sent to the addr/port from
> > > > which they came (the MG) and so do not violate the general rule, but
> > > > this does seem to fit with the general philosophy (which we would be
> > > > changing) that the new MGC is taking over role of original even for
> > > > pending transactions.
> > > >
> > > > --
> > > > Waiting for the other shoe to drop but hoping its a one legged man.
> > > > ------------------------------------------------------------
> > > > Terry L Anderson             mailto:[email-masked]
> > > > Tel:908.582.7013   Fax:908.582.6729
> > > > Lucent Technologies/INS/Voice Over IP Access Networks
> > > > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> > > > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla
> >
> > --
> > Waiting for the other shoe to drop but hoping its a one legged man.
> > ------------------------------------------------------------
> > Terry L Anderson             mailto:[email-masked]
> > Tel:908.582.7013   Fax:908.582.6729
> > Lucent Technologies/INS/Voice Over IP Access Networks
> > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
> > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

--

------------------------------------------------------------
Terry L Anderson              mailto:[email-masked]
Tel:908.582.7013   Fax:908.582.6729
Lucent Technologies/INS/Voice Over IP Access Networks
Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974
http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

---

From: Terry L Anderson <[email-masked]>
Date: Fri, 18 Jan 2002 14:28:09 -0500

To summarize:
Option #1:

Option #2:

--

---

From: Christian Groves <[email-masked]>
Date: Mon, 21 Jan 2002 13:48:21 +1100

G'Day Terry,

I'm in a favour of a simple rule. However if you adopt the rule that the
replies ALWAYS go the addr/port from which the request came then you
need you should make a note that the failed MG probably will never
receive the replies, in which case sending them there is redundant.

If the new MGC doesn't have state of the transaction it will simply
discard the transaction responses. The MGC that doesn't have state it
will need some mechanism to clear calls or audit to find out state. From
a security point of view its probably not a problem because it will just
discard the message response.

An MGC that does have state will use the transaction response and
continue using the MG. As state is shared the secondary MGC should know
that the primary went down and will know to accept the transaction
responses.

The MG will know to send the response to the new secondary MGC because
it received an authenticated command from the primary MGC. Again I'm not
sure that there's a security problem.

THE underlying issue is your question 1: should the protocol use a
simple rule that replies ALWAYS go the the source from which the request
came, or have exceptions? From the above I think there's an exception.

Regards, Christian

> > > > > changing) that the new MGC is taking over role of original even for

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Mon, 21 Jan 2002 13:48:21 +1100

G'Day Terry,

Regards, Christian