Subject: Re: Preconditions

From: Tom-PT Taylor <[email-masked]>
Date: Mon, 24 Jan 2000 18:42:42 -0600

This issue got a brief but thorough airing in the thread "questions
regarding hook state in residential gateways", initiated by Wai-Tak Siu and
running from 19-24 November 1999.  It's my fault for not stating a
resolution to the thread.  Rather than do so immediately I'll run over the
elements of the discussion.

First: what is the problem?  In the note below, Michael says there is a
potential problem of persistent state mismatches between the MG and the MGC.
Wai-Tak's problem statements (Nov. 19 and Nov. 20) illustrated this for the
particular case of line off-hook before the MG-MGC association was fully
established.

Note the elements of this situation: there is an objective device state
which changes autonomously, outside of the control either of the MG or the
MGC.  It is possible for the MGC to make an incorrect assumption about this
initial state.  In the particular case of line off-hook, the condition is
self-correcting, at the potential cost of subscriber discontent.  The
solution preferred by Michael and Wai-Tak is that the MG be allowed to
report the actual state of the line at the time that the MGC takes control.
Some of the discussion in the thread focussed on ways to do this, whether
via a state mismatch report or via a report of the original off-hook event.
In the latter case the event might either have been preserved in a buffer or
inferred from the current line state.

There was an objection (Jon Steer, seconded by Brian Rosen) that "state" is
implementation-dependent in the first place, and that we can't just solve
this for lines without solving it for other termination types too.  I'll
just suggest that in the very specific case of lines, hook state is pretty
clear -- it's not just an artifact of the implementation.  Given that there
is a package specifically devoted to lines, I would think that we could
achieve a satisfactory solution for that one case.  This is NOT, as Michael
suggests, elementary wisdom from MGCP -- it is a special solution to a
special case.

So the obvious question after that : what about the general case?  My
experience with distributed systems in the past is that auditing is a way of
life if you want to keep the system sane.  It may take a few hours to
complete one audit cycle, but it's better than nothing.  Of course, an audit
wouldn't catch the line hook state mismatch as our protocol currently stands
-- it will only catch discrepancies between what the MGC thought the MG
executed and what the MG has actually executed.  It seems reasonable,
therefore, that we have to identify externally-driven states wherever we can
find them and make sure the related package definitions handle them
properly.

Hope this helps to frame the discussion.

> -----Original Message-----
> From: Michael Thomas [SMTP:[email-masked]]
> Sent: Saturday, January 22, 2000 3:22 PM
> To:   [email-masked]
> Subject:      Preconditions
>
> Rosen, Brian writes:
>  > Frankly, I don't think it matters a whole heck of a lot what happens in
>  > cases
>  > like this, unless there is some possibility that the MG and the MGC
> will not
>  > sync quickly.
>
>    That's a very big "unless".
>
>  > They do in this case -- the user hangs up, and then the state
>  > is consistent, the next time he goes off hook, the right thing happens.
> If
>  > anyone
>  > can define a case that doesn't converge like this, please speak now,
>
>    A device control protocol like MEGACO is utterly
>    at the mercy of a shared view of the device's
>    state. If the MG and MGC are out of sync and the
>    MG has no way to convey that within the protocol,
>    the protocol is broken. Period. Relagating such things
>    to audits is even more broken, because MGC's in the
>    real world have about zero incentive to do what
>    amounts to device state polling -- which does
>    not scale for high fanout devices like residential gateways.
>
>  > I recommend we say "thanks for sharing"
>
>    This is a base functionality of MGCP -- the
>    only protocol which has any track record
>    thus far. Is this more Anything But MGCP
>    hubris again?
>
>    I would say that the onus is on the naysayers
>    to actually prove there does not exist any
>    unrecoverable and non self-healing state
>    mismatches. It is completely unreasonable for
>    those who would like to have a more robust
>    protocol to prove a negative.
>
>                 Mike