Subject: [Megaco] Replies to requests from failed MGC

From: Terry L Anderson <[email-masked]>
Date: Tue, 14 Aug 2001 17:57:18 -0400

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

---

From: Christian Groves <[email-masked]>
Date: Mon, 20 Aug 2001 15:34:11 +1000

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?

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?

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.

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?

Cheers, Christian

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

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

---

From: Terry L Anderson <[email-masked]>
Date: Mon, 20 Aug 2001 10:44:50 -0400

> Shouldn't this state "handoff" instead of "failover" as handoff is sent

You are right.  Hadn't noticed this, but MG should never receive ServiceChange
message announcing a failover".

> 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

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.

For handoff the rule works since the old MGC can send/accept replies for
outstanding transactions before going 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).

> 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.

> 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).

---

From: Christian Groves <[email-masked]>
Date: Tue, 21 Aug 2001 18:01:22 +1000

G'Day Terry,

Please see comments below [CHG].

Christian

> - because entity at another addr may not know about request

[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.

> 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.

> 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.

> #1 seemed to be the conclusion of all mail threads I found (3 or 4 since Jan

[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.