Formal specification & Panacea for ServiceChange logic; RE: Version of "Disconnected" ServiceChange messages

I got some side comments.

1) FDT (Formal Description Techniques)
It is difficult to solve the logic for the use case indicated by Elad in a manner which satisfies everyone. This is just due to the nature of the underlying specification technique used in H.248 (and the majority of other protocols; please note that this is not an H.248-specific issue).
If you think about the problem, then it becomes obvious that we got deficiencies due to the prose-based specification by using current NLD-spproach (natural language description, see Z.450) for our H.248 protocol specification. 

We got that different interpretations (not for all, but for some few ServiceChange use cases) due to the semantical overloading of some "key" words. Keeping the NLD-approach and trying to solve ambiguities would demand for further definitions in the "term" section (clause 3/H.248.1; e.g. defining the semantic of words "terminating", "commanded", etc in the context of ServiceChange), and additional IG clarifications. 
We do that already, - but a textual (prose) change at one place might be then still inconsistent at other places.

You know that the deficiencies of NLD may be addressed by using a FDT method (formal description technique by using a formal specification language).

We did discuss FDT usage for H.248 already in the past (see e.g. http://ftp3.itu.int/av-arch/avc-site/2005-2008/0502_Mel/AVD-2610.zip).
It was just too late then, - and FDT usage needs volunteers due to the significant effort.
I would support any FDT activity in H.248.1 Version 4, - but this would not solve problems resulting from deployed H.248 implementations which followed a certain semantical interpretation. 

2) Stateful CA modelling
Trying to solve the use case indicated by Elad could be facilitate with an underlying state model for the Control Association. We don't have anyone so far.
We did discuss this also already a couple of times in the past, see eg.
http://ftp3.itu.int/av-arch/avc-site/2005-2008/0703_She/AVD-3003.zip
http://www.ietf.org/mail-archive/web/megaco/current/msg07799.html

It could be worth in analyzing again a CA state model under H.248.1 Version 4 IMO.

3) Panacea for ServiceChange
We know that neither FDT usage for ServiceChange specification, nor state modelling the H.248 CA would lead to an entire, unambiguous specification of the theoretical solution space.
So, what would we gain then moving from NLD to FDT, and/or from stateless to a stateful CA model?
I would say: if current NLD approach is covering (let's say) 80% of possible ServiceChange scenarios, then an FDT approach would be at least also cover 80%, but less than 100%.
However, we would got all the advantages of FDT, like e.g. automatic inconsistency detection, deadlock detection, etc. [toward to automatic code generation ("manager like that, protocol implementors know the free-lunch-theorem";-))].
This is the major advantage I see (beside the formally specified logic).

4) Probability distribution of ServiceChange procedures 
Every possible ServiceChange scenario is occuring in a real deployment with a probability between 0 and 1 (within a bounded time window).
E.g., a registration procedure has a probability of 1, the scenario indicated by Elad might be close to 0 (perhaps below 10^-5).
We can't afford in specifying the (let's say) 20% of not yet covered (in H.248.1) ServiceChange procedures, if they would be related to a percentile of <1% of the probability distribution of theoretical ServiceChange procedures.
I would prefer an engineering approach by either
a) bundling the rare and exceptional cases, or
b) mapping them on other ones, or
c) breaking them (e.g. a 4-step (seldom) ServiceChange cycle could be broken in two 2-step cycles), 
of course, on the expenses of non-optimized efficiency for such procedures.

Elad, im not saying that we should keep unambiguities in our NLD-based Annex F, § 11 and § 7 in H.248.1 on ServiceChange.
But I would wonder about the probability of your outlined SC use case?
Right, estimation such a probability would be a quantitative approach for ServiceChange.
Knowing that N parties would come to N different probability estimations.

We made an attempt in TISPAN by introducing quantitative modelling into ServiceChange (by focusing initially on so-called recovery concepts) see:
13tTD374 "WI-03051 H.248 System Management - Conclusion "MGC Out-of-Service" - Immediate vs Delayed Failover"
http://docbox.etsi.org/TISPAN/TISPAN/99-Archive/2007/50-20070514-Sophia-13ter/13tTD374_WI-03051_H.248_System_Management_%E2%80%93_Conclusion_%E2%80%9CMGC_Out-of-Service%E2%80%9D_%E2%80%93_Immediate_vs_Delayed_Failover.doc

If you look at the Figure for "Probability model for 'unavailability' conclusions" then you could simplify possible "proceeding decisions" by following two strategies: (cold/warm) CA restart vs CA re-newal attempts (or whatever else).

I'm convinced that quantitative estimations may solve some ServiceChange problems (of course, a mutual agreement (profile spec) need to record the availability & modelling assumptions of the involved H.248 entities of that H.248 domain).


Best regards, Albrecht

PS
Just to confirm again that this email is not providing a solution proposal for H.248.1 IG for your outlined issue ("which is valid in my understanding").



> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Elad Chomsky
> Sent: Dienstag, 15. April 2008 23:17
> To: Kevin Boyle; Waitzmann Carsten
> Cc: [email protected]
> Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages
> 
> Hello Kevin,
> 
> If I understand you correctly, it would seem that my original 
> understanding of Annex F.3.6 was very different from its original 
> intent. I would be very grateful if I could run by you what I infer 
> from your response (below); just to make sure I got it right this 
> time:
> 
> ----------
> 
> An MG can detect a disconnection of the control-association; for 
> example, through the timing-out of an MG initiated transaction. When 
> the MG detects such a disconnection, it still considers the 
> control-association as active. It handles any requests received on 
> that control-association normally; and issues Notify requests over it 
> when events are detected.
> However it will also send a "Disconnected/900"
> ServiceChange on the control-association; to inform the MGC that there 
> was a temporary interruption of the connection.
> 
> If the MGC fails to respond to the "Disconnected/900" 
> ServiceChange request (i.e. this request also times-out), the MG 
> considers the control association as down. It will no longer accept 
> requests received on this control-association.
> Instead it will try registering with other MGCs using a "Failover/909" 
> ServiceChange. Whenever its configuration indicates that it should try 
> registering with the original MGC, it would instead try to renew the 
> original control-association using a "Disconnecetd/900" request. Note 
> that this "renewing" is not a registration; i.e. the MG never tries to 
> re-register with the original MGC.
> 
> ----------
> 
> If this is correct, what error should the MGC return when it receives 
> a "Disconnected/900" ServiceChange but knows nothing about an existing 
> control-association? Some error must be returned, as otherwise the MG 
> will never be able to connect with that MGC.
> 
> Thanks,
> Elad
> 
> -----Original Message-----
> From: Kevin Boyle [mailto:[email protected]]
> Sent: Tuesday, April 15, 2008 6:42 PM
> To: Elad Chomsky; Carsten Waitzmann
> Cc: [email protected]
> Subject: RE: [Megaco] Version of "Disconnected" ServiceChange messages
> 
> I believe that this is being made far more complicated than it was 
> intended to be.
> 
> The wording about "terminating" the control association was put in 
> place because there has to be some point when the MG stops listening 
> to the original association in order to establish a new one.  But if 
> no one else accepts the registration, why can't the original be 
> "picked back up"?
> The MGC from the previous control association would still think it was 
> the same control association.
> 
> The intent of Disconnected has always been that the comms were lost on 
> the control association and they are being reestablished.  Given this, 
> it is not actually a re-registration.
> 
> Registration to establish a new control association must always use 
> version 1.  This is to allow version negotiation to take place at the 
> lowest common denominator, as support of later versions implies 
> support of earlier versions.
> Disconnected is not establishing a new control association, but is 
> repairing one that was the subject of comms loss.
> This means that the Disconnected should be encoded per the version 
> negotiated on the previous control association between the two 
> entities.
> If the MG wishes to renegotiate the version, then it can do so once 
> comms are re-established.
> 
> Kevin
> 
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Elad Chomsky
> Sent: Tuesday, April 15, 2008 6:27 AM
> To: Carsten Waitzmann
> Cc: [email protected]
> Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages
> 
> Hello Carsten,
> 
> Like you, I dislike the fact that the same method/reason combination, 
> "Disconnected/900" is used both to renew a control association and to 
> re-register once that control association was terminated. However 
> changing this behavior will require making a change to Annex F.3.6.
> Currently this annex clearly states that:
> 
> "If the MG exhausts its list of MGCs without successfully establishing 
> a control association, the MG waits a random amount of time and then 
> attempts registration with the MGCs in its list again, starting with 
> the MGC from the original control association. The MG will send a 
> ServiceChange with a ServiceChangeMethod of "Disconnected" to the MGC 
> from the original control association each time the MG attempts to 
> contact it."
> 
> So, "Disconnected/900" is clearly used for re-registration as well.
> 
> If this behavior is changed, I would suggest that re-registration will 
> use "Failover/909". I see little reason to differentiate between the 
> original MGC and all others once the control association is 
> terminated.
> 
> I would still be really grateful for any views regarding the
> H.248 version that should be used when encoding the two types of 
> "Disconnected/900" (i.e. the "renew" one and the "re-register" one).
> This point is actually causing us some interoperability problems.
> 
> Many thanks,
> Elad
> 
>  
> -----Original Message-----
> From: Carsten Waitzmann [mailto:[email protected]]
> Sent: Tuesday, April 15, 2008 12:54 PM
> To: Elad Chomsky
> Cc: [email protected]
> Subject: Re: [Megaco] Version of "Disconnected" ServiceChange messages
> 
> Hello Elad,
> 
> I think that's a valid point.
> 
> According to H.248 Sup.7 "renewal" is considered as follows:
> The term "refreshment" (also known as "renewal") of an H.248 CA is 
> related to the application of ServiceChange method and reason 
> combination of {Disconnected, #900}. CA refreshment is characterized 
> by situations of a previous existing CA, a subsequent short-term 
> interruption, and then a continuation of the previous CA without any 
> MG (re-)registration step(s).
> 
> Furthermore, F.3.6 says that the original H.248 CA is terminated 
> whenever the MG attempts to re-register with another MGC ("failover").
> As at that point the original H.248 CA is terminated, it cannot be 
> renewed anymore and therefore a new CA has to be established. In other 
> words, the scenario escalates from "lost communication" to "lost 
> control association". Thus I think it would be appropriate to say that 
> in a second (third,
> ..) round when the MG tries to re-register with the MGC of the 
> original CA, the MG will use SC method "restart".
> I don't think that "disconnected/900" should be admitted as mean for 
> re-registration.
> 
> best regards
> Carsten
> 
> 
> 
> 
> Elad Chomsky wrote:
> > Hello H.248 heavyweights,
> > 
> > I have a question regarding the H.248 version that should
> be used when
> 
> > encoding a "Disconnected" ServiceChange request.
> > 
> > The way an MG utilizes "Disconnected" ServiceChange requests is 
> > described under Annex F.3.6 of H.248.1:
> > 
> > 1/ When an MG detects that it became disconnected from its MGC, it
> tries
> > to re-establish its control-association by sending a "Disconnected"
> > ServiceChange request to that MGC. If the MGC replies to
> request, the
> > control-association continues without interruption.
> > 
> > 2/ If the MGC fails to reply to the ServiceChange request above, the
> MG
> > starts traversing its list of possible MGCs and tries
> registering with
> 
> > each of them. The MG will use a "Disconnected" ServiceChange when
> trying
> > to register with the original MGC and a "Failover" 
> ServiceChange when
> > trying to register with any other MGC.
> > 
> > 3/ The control-association is terminated as soon as the MG sends a 
> > "Failover" ServiceChange request to an MGC.
> > 
> > Now according to (2) above, the "Disconnected" ServiceChange can be 
> > considered as a registration. Therefore, according to
> clause 11.3 of
> > H.248.1, it must be encoded according as a version 1
> message. However
> it
> > also appears that in (1) above, the "Disconnected" ServiceChange is
> sent
> > over an existing control-association; and therefore should
> be encoded
> > according to the association's negotiated version.
> > 
> > Is this the correct interpretation? I.e. Must a "Disconnected"
> > ServiceChange be encoded using version 1 if no control association 
> > exists and using the negotiated version if a control-association
> exists?
> > Or should one of these versions always be used?
> > 
> > Many thanks in advance,
> > Elad Chomsky
> > 
> > _______________________________________________
> > Megaco mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/megaco
> > 
> 
> --
> Alcatel-Lucent Deutschland AG
> Sitz der Gesellschaft: Stuttgart - Amtsgericht Stuttgart HRB
> 4026 Vorsitzender des Aufsichtsrats: Michael Oppenhoff
> Vorstand: Wolfgang Weik (Vors.), Dr. Rainer Fechner, Juergen 
> Poesinger, Alf Henryk Wulf 
> _______________________________________________
> Megaco mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/megaco
> _______________________________________________
> Megaco mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/megaco
>