Subject: Re: Cisco SG16: Service Change

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 4 Feb 2000 13:46:21 -0500

Hi Flemming

Comments to your comments below

> Actually, there has. v13 made some changes from v12 in this
> area. In v12,
> "forced" would had an effect similar to subtract on the affected
> termination, where as in v13, all of a sudden it's the MGC
> responsibility
> to figure out what the state of the MG is. Similarly, "restart" in v12
> implied the affected terminations were not associated with any Context
> (except for the NULL context presumably), where as v13 does
> not. Again, the
> MGC will now have to figure out what state the MG is in when
> it receives a
> "restart", 'cause it can't make any assumptions whatsoever.
I'd have to wade through a lot of messages to figure out when we
decided that the MGC had to Subtract to keep state consistent
on a ServiceChange, but I remember it before V12.m  At any rate,
the MGC doesn't have to "figure out" the state of the MG, all it
has to do is Subtract the affected terminations.

The problem is this: if the MG, on it's own, disconnects the
terminations from the context, then the MG and the MGC don't
agree on state, and in particular, commands in progress get screwed up.
While the MG can return errors subsequent to failing the
connections, MG and MGC state is inconsistent.  If the MGC does
the subtract, then the state is always consistent.  One particular
issue is whether the whole context should be taken down, or just
the failed terminations.  The MGC knows what it wants to happen,
the MG does not.  There doesn't seem to be any problem in having the MGC
always be the one that does the subtract.

> >
> > If you cold-start an MG, it will come up in a known state, and
> > Restart to it's MGC, primary or secondary.  I think we can all
> > agree it does this.
>
> Yep, but what about warm-start ?
Define warm start - Restart of Root is equivalent to cold start
Handoff is a no-state-change thing
Failover is the same
>
> >
>
> > If the MG itself FORCES terminations out of service, then the MGC
> > has to do the subtract.  There is no ambiguity of state.  No
> > secondary MGC is involved.
> >
> > If the MGC FORCES terminations out of service, it must do the
> > subtract also, and there is no ambiguity of state.  No secondary
> > MGC is involved.
> >
> > Somehow, your problem statement gets into a Handoff, or Failover
> > case, where, for some reason, you posit a working primary MGC
> > getting one message, and a working secondary MGC getting
> another one.
> > On a failure of an MG, there is no change of MGC, so the restart
> > looks like an initial registration, and all the terminations
> > should be in a known state.
>
> Yes, they should, and that's the point. When you get a
> "restart", you know
> you are in well-known *clean* state.
Confusion on terminations going in and out of service and the
MG going in and out of service.

Restart applied to root is cold start; you are in a well-known
state.  You don't see Restart in failover/handoff, state is not
changed, new MGC must have state from some outside mechanism,
or Audit.
>
>
> >
> > On an MG initiated failover, the MG registers with the secondary
> > with Failover, not Restart.  The MGC could send Forced to
> > the primary, but the MG is considering it dead, and probably
> > wouldn't do it.  At any rate, failover DOES require an audit
> > by the secondary MGC as it should.
>
> Ah yes, but what happens when the MG sends "forced" to the
> MGC (MGC-A), and
> a little later it tries to register with MGC-A who meanwhile crashed.
> Consequently, MG goes through it's list of secondaries and
> finds MGC-B. Are
> you saying it no longer uses "restart" but "failover" ?
So this is a multiple error problem, the MG is dieing slowly.
First some of its terminations go belly up, then before it can
restart them, it loses its control association and has to
re-register itself, and on top of that, it's MGC died!  Poor MG,
the whole world is falling down!

I rather doubt this case is worth worrying about too much :)

> Regardless of what the answer is, it seems like there is a
> need for a state
> transition diagram for the MG and MGC in the text somewhere. It is not
> exactly clear what all these rules add up to, and there's clearly some
> underlying logic expected.
Not an unreasonable request, but not something I would hold up
ITU or IETF for.

> As for requiring an audit after failover, that seems rather
> strange to me.
> Since failover supposedly is transparent (don't loose any
> messages, right
> ?) why would you need that ? You can of course recommend it
> as good MGC
> practice if you think you don't have transparent failover,
> but I thought
> that was the intent of "disconnected".
Up to your implementation.  If your MGCs have a way to discover
the state of the MG without audit, terrific.  If they don't,
or even if they do, an Audit would be a good thing to check things
out.

> >
> >
> > On an MGC initiated failover, you use Handoff.  Again, the MGC knows
> > what the state is, but the secondary doesn't.  It must Audit, but
> > that is as it should be.
>
> Maybe it does, maybe it doesn't. That's MGC internals, right ?
Agreed, doesn't change the rules or the current text

> >
> >
> > There are no other cases of Forced or Restart that I know about.
> >
> > > Section:         7.2.8 (ServiceChange), numbered item six
> > > Category:     Editorial/Technial
> > > Issue no.:     14.7
> > > Issue:          The draft text for "Failover" specifies that
> > > "..., and sent
> > > from MG to (new) MGC in response to the MG having received a
> > > ServiceChange
> > > with ServiceChangeMethod equal to Handoff". It would seem
> to be more
> > > consistent if the MG sent a "Handoff" rather than a
> > > "Failover" to the (new)
> > > MGC in response to a handoff from the old MGC.
> > > Proposal:     It is proposed, that above text segment is
> > > moved from the
> > > "Failover" method to the "Handoff" method.
> > > Status:
> > I'm okay with this, although I think it's a nit
> >
> > >
> > > Section:         7.2.8 (ServiceChange), fifth last paragraph
> > > Category:     Technical, Editorial
> > > Issue no.:     14.8
> > > Issue:          The draft text specifies that "The MGC
> shall use this
> > > Addres, if specified, in its response to the ServiceChange
> > > command and any
> > > subequent commands and responses" and "The MG shall use this
> > > address for
> > > any subsequent communication with the MGC". While it makes
> > > sense to require
> > > commands to be sent to this address, it is generally not a
> > > good idea to
> > > require this for responses, e.g. for clustered systems.
> Furthermore,
> > > Section 9 (Transport) also specifies that "Responses to
> > > commands are sent
> > > back to the source address of the commands"
> > > Proposal:     It is strongly recommended, that commands will
> > > be sent to the
> > > address specified while responses will always be sent to the
> > > source address
> > > they came from.
> > > Status:
> > I agree with this.  The text is inconsistent, so something needs
> > to be changed.  Chip's proposal seems the most reasonable way
> > to resolve it
> >
> > >
> > > Section:         7.2.8 (ServiceChange), third last paragraph
> > > Category:     Editorial
> > > Issue no.:     12.25
> > > Issue:          The draft text specifies that "The
> > > ServiceChangeMethod
> > > shall be "forced" for this usage". This is inconsistent with the
> > > description in Section 11.2  which specified a
> ServiceChangeMethod of
> > > "Restart".
> > > Proposal:     It is recommended that the above text be
> > > modified to use a
> > > ServiceChangeMethod of "Restart" instead.
> > > Status:
> > >      v13: CLOSED. Text has been modified.
> > >
> > >
> > > Section:     7.2.8 (ServiceChange), last bullet list
> > > Category:     Technical
> > > Issue no.:     13.13
> > > Issue:          The draft text specifies that "Profile required if
> > > terminationID is not ROOT, optional otherwise". However there
> > > may not be a
> > > profile, in which case it makes little sense to require it.
> > > Secondly, it
> > > would seem to make more sense to require a profile when the
> > > terminationID
> > > in fact is ROOT as that would be the initial registration.
> > > Proposal:     It is proposed, that the text is changed in
> > > accordance with
> > > above.
> > > Status:
> > >      v14: OPEN. No relevant text changed.
> > How about: Profile is Required if the termination ID is ROOT,
> > and the entity supports a profile, optional otherwise.
> >
> > I agree the text is wrong, and some change is required.
> >
> > >
> > > >
> > > >
> > > >Section:        11.2  Category:       Technical  Issue:
> > >     When a
> > > >gateway starts, it generates a restart ServiceChange  to the
> > > MGC. If the
> > > >MGC's response to the ServiceChange is lost while a  later
> > > command is
> > > >received by the gateway, how this command is handled is  not
> > > specified in
> > > >the draft text.  Proposal:       It is recommended that the
> > > gateway will
> > > >return an error.
> > > >
> > > >v13 Status:     OPEN. No text changed.
> > > >
> > > >[[TomT]]  Agreed in principle.  This triggered thoughts
> of flooding
> > > >attacks where the attacker masquerades as the MGC which it
> > > is indirectly
> > > >trying to flood with error messages.  I suppose we're OK
> so long as
> > > >authentication failures are discarded silently.  Anyway,
> I'll add a
> > > >"clarification" to section 8.3 stating that the MG should
> > > respond with an
> > > >error to authenticated messages from MGCs with which the
> MG is not
> > > >currently associated.   It's not quite so simple for
> MGCs receiving
> > > >messages from strangers -- I guess the MGC has to look
> > > inside to determine
> > > >whether to accept them.
> > > v14: CLOSED. An error will be returned
> > > >
> > > >
> > > >Section:        11.2  Category:       Technical  Issue:
> > >     The draft
> > > >text specifies that "If the MGC accepts the MG,  it will send a
> > > >Transaction Accept, with the MGCIdToTry set to itself. If
> > > the MG receives
> > > >an MGCIDToTry not equal to the MGC it contacted, it send a
> > > ServiceChange
> > > >to the MGC specified in the MGCIdToTry". It is inconsistent
> > > to on one
> > > >hand accept the transaction as successful, yet on the other
> > > hand  require
> > > >the MG to examine the MGCIdToTry returned to determine if
> > > >the  registration really was successful or not.
> Examination of the
> > > >syntax  reveals that this is part of a larger problem where
> > > >unsuccessful  transactions, actions and commands are not
> > > able to return
> > > >any other  information than an ErrorDescriptor which can
> > > only contain an
> > > >error code  and text.  Proposal:       It is recommended
> > > that the above
> > > >procedure is replaced by  return of an error code and
> > > another MGCIdToTry
> > > >if the registration did not  complete. Furthermore, it is
> > > recommended that
> > > >ErrorDescriptors are extended  to allow return of other
> information
> > > >(essentially CommandReply) than only  an error code and text.
> > > >
> > > >v13 Status:     OPEN. No text changed  [[TomT]]  As I see
> > > it, redirection
> > > >is different from a transaction error.  The MGC processed
> > > the command
> > > >successfully, and the response contains useful information.
> > > An error
> > > >should be thought of as a situation where the responder
> > > reached a dead end
> > > >when it tried to comply with the request.  In general
> > > recovery from an
> > > >error is pretty basic: kill the call.  In special cases the
> > > error code and
> > > >context should give enough information for recovery.
> > > Not really. Think of SIP, HTTP, MGCP, etc. There are numerous
> > > return codes
> > > that have nothing to do with "errors" per se. In reality,
> > > these "error
> > > codes" are really "return codes" and maybe that's where the
> > > confusion arises.
> > I'm with Tom on this one, and I'll further point out you can't do
> > what Chip proposes since if you get an Error descriptor, you
> > won't get the Service descriptor with the MgcIdToTry!
>
> Yes, and as pointed out above, that's a fundamental problem
> that seems to
> have no motivation and certainly not be in line with current
> experience and
> practice.
I don't understand.  Are you saying that when you have an error,
you also expect to see normal responses?  I usually don't expect
such things.  Are you saying MGCP does that?  Could be.

It's NOT an error, it's a refusal to accept the MG for service.

Seems like you are arguing that it should be an error, and
despite the fact that it's an error, you should get the
Service Descriptor back in addition to the Error Descriptor.
That's a pretty big change, and I'd say unwarranted.

While we could have had "Error Codes" be interpretted as
"Return codes", and we could have had information necessary
to proceed contained in error messages, we didn't.  I can't see
changing that now, when the mechanism we have now works.

---

From: Flemming Andreasen <[email-masked]>
Date: Fri, 4 Feb 2000 14:57:02 -0500

Hi Brian

Some comments below

-- Flemming

> has to do is Subtract the affected terminations.

No, it's worse than that. The MGC first has to find out if these
terminations are associated with any contexts right now, as I tried to
explain in the primary/secondary MGC "restart" case below.

> always be the one that does the subtract.

But they get screwed up anyway since the serviceState by definition is "Out
of Service" after "forced", so what's the advantage (I've already pointed
out the disadvantages) ?

There are clearly some semantic expectations associated with these
serviceStates. Again, I think these need to be spelled out clearly and a
state transition diagram for transition between the serviceStates needs to
be included.

> Define warm start - Restart of Root is equivalent to cold start

In that case, not even cold-start has a known state (there may or there may
not be exising contexts with terminations when you get a "restart" ROOT). By
warm-start, I meant some "restart" after initial registration had succeeded
previously.

> Handoff is a no-state-change thing

Agreed.

> MG going in and out of service.

That's possible. Let's get the state transition diagram to clear it then.

> I rather doubt this case is worth worrying about too much :)

Well at least we agree there's a problem then. I don't think it's proper
protocol design to ignore that.

> Not an unreasonable request, but not something I would hold up

It's more important to get it out there than actually specifying it in
detail ? I'm sure you could put this together fairly quickly, and since
there is a lot of new text here and clearly some confusion, I don't think
that's an unreasonable request.

> or even if they do, an Audit would be a good thing to check things

Sounds good - as long as the protocol state machine doesn't require it.

> such things.  Are you saying MGCP does that?  Could be.

Depends on how you define an error. I prefer thinking of it as "return
codes". Some of these imply the transaction is done and no further action is
to be taken (e.g. like a 200 OK). Others imply, that the transaction is
done, but further action is needed, e.g. a 3xx response in SIP, or similar.
Finally, you have the class of response that truly indicate that something
went wrong, i.e. an error.

> changing that now, when the mechanism we have now works.

That's a valid concern (not quite sure what the errorDescritpor in
AuditReturnParameter is doing though), however I do think you will end up
regretting it.

--
---------------------------------------
Flemming Andreasen
Cisco Systems
---------------------------------------