Subject: Re: Descriptor processing order

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 14 Mar 2000 09:22:00 -0500

Good point.  I think we should add text that says
descriptors are processed in the order they appear
in the command, just like commands are processed
in the order they appear in the action.

Brian

> -----Original Message-----
> From: Chip Sharp [mailto:[email-masked]]
> Sent: Monday, March 13, 2000 8:33 PM
> To: [email-masked]
> Subject: Descriptor processing order
>
>
> Due to a previous question on event handling, I went through
> the output of
> SG16 (TD37) looking for text on the ordering of processing of
> descriptors.
>
> However, I could find no text in the document that describes
> in what order
> a MG or MGC should process descriptors.  I was specifically
> wondering if
> the TerminationStateDescriptor was processed before the
> EventsDescriptor.  This has implications in that the order of
> processing
> the value of the EventBufferControl parameter in the
> TerminationStateDescriptor and the EventsDescriptor will
> affect how events
> in the EventBuffer are processed.
>
> If TerminationStateDescriptor is processed first and
> EventBufferControl=Off
> (previous LockStep), then all events are discarded.  If
> EventsDescriptor is
> processed first then at least one more event will be reported
> before the
> EventBuffer is flushed (ignoring the previous discussion as
> to whether this
> is desirable or not).
>
> It seems there may be any number of conditions like this that
> will depend
> on ordering of processing of descriptors in the command.
>
> Shouldn't there be some basic text in the spec that either
> specifies that
> the receiver of a command should process the descriptors in the order
> received or that the receiver can process them in any order
> desired?  I
> prefer the former.  The latter seems a little indeterminate.
>
> If there is already text of this nature in the document,
> please educate me
> as to its location.
>
> Thanks,
> Chip
> Support NetAid!  http://www.netaid.org
> --------------------------------------------------
> Chip Sharp                 Consulting Engineering
> Cisco Systems              Telco Bio-region
> Reality - Love it or Leave it.
> --------------------------------------------------
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Wed, 15 Mar 2000 10:00:31 -0500

Thanks for pointing this out.  I believe we should change
the ASN.1 to allow descriptors in any order, and specify that
they are processed in the order received.  This allows the MGC
to control what happens, in what order.

If we were to go in the other direction; forcing a particular
order, then we get into a debate about the proper order, for which
I suspect there is no one right answer.

Brian

> From: Steven Magnell [mailto:[email-masked]]
> Sent: Wednesday, March 15, 2000 4:55 AM
> Subject: Re: Descriptor processing order
>
>
> This discussion exposes a syntactic difference between the
> binary and text
> encodings of the protocol. The binary encoding describes the list of
> descriptors in the Add/Move/Modify commands as a SEQUENCE
> which follows the
> order given by the abstract API descriptions of the commands. The text
> encoding, on the other hand, specifies only a list of
> parameters where the
> parameters are the separately defined as the descriptors, allowing
> variations in the order of descriptors.
>
> Chip's expectation that the order of descriptors can be
> reversed in order
> to affect the order of processing is only possible using the
> text encoding.
>
> Given this difference either the binary encoding syntax
> should be changed
> or the order of descriptor interpretation should follow the
> order given in
> the abstract API.
>
> steve
>
> At 07:48 AM 3/15/00 +0100, Christian Groves wrote:
> >G'Day Chip and Brian,
> >
> >Sounds like a good idea it what I've always assumed (but as
> we've found
> >out several times with this protocol, assumptions are dangerous). Is
> >this something for the implementor's guide or an error fix?
> >
> >Cheers, Christian
> >
> >Chip Sharp wrote:
> >>
> >> I think this would resolve ambiguities and possible
> anomalous results on
> >> descriptor processing.  If the MGC wants the MG to process
> the descriptors
> >> in a particular order, it would then have control.
> >>
> >> In the particular example I cited, I would assume that the
> MGC would always
> >> place TerminationStateDescriptor before EventsDescriptor
> (thus having
> >> EventBufferControl processed before the new
> EventsDescriptor); however, it
> >> would have the ability to reverse the order if it needed to.
> >>
> >> Chip
> >>
> >> At 09:22 AM 3/14/00 -0500, Rosen, Brian wrote:

---

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 20 Mar 2000 09:08:07 -0500

I also agree commands should be atomic.

We aren't forgetting that the problem of descriptor
order isn't related to failure, right?

Brian

> From: Christian Groves [mailto:[email-masked]]
> Sent: Monday, March 20, 2000 1:10 AM
> G'Day Chip,
> I completely agree with what you say. Command's should either
> succeed or
> fail. What I was concerned about is something like playing a
> signal from
> a signal descriptor and then the MG changes a property in a local
> descriptor which fails. This is all done in a modify command. The
> command fails because of the error.
>
> Hopefully the MG doesn't try to return the state to what it was before
> the command. ie. Once a signal is played you can't get it back. It was
> this clarification about what the MG does that I was looking for.
>
> Cheers, Christian
>
> Chip Sharp wrote:
> >
> > I'll leave it up to the experts, but I imagine it would be
> similar to a
> > Q.931 SETUP message.
> >
> > If the switch executes one Information Element and the next
> one fails, the
> > switch treats the entire SETUP message as in error.
> >
> > I believe there should be atomicity at some level.  If we
> go one level
> > deeper, we could look at what happens within a descriptor
> in the ordering
> > of parameters.  If one parameter succeeds and the next
> fails, the MG has to
> > recover.  I tend to think that a command should be atomic.
> It either
> > succeeds or fails.  I think independence of execution of
> descriptors would
> > make it even more difficult than it already is for the MGC
> and MG to remain
> > in synch (and sane).
> >
> > Chip
> >
> > At 03:39 PM 3/17/00 +1100, Christian Groves wrote:
> > >G'Day Abdallah,
> > >
> > >I can buy saying that descriptors are processed in order
> but what do we
> > >gain by adding "All commands are atomic operations, either
> succeed or
> > >fail as a whole". What does this really mean??
> > >If one decriptor is executed and the next descriptor fails
> what does the
> > >MG do?
> > >
> > >Christian
> > >
> > >Flemming Andreasen wrote:
> > > >
> > > > Sounds good to me.
> > > >
> > > > -- Flemming
> > > >
> > > > Abdallah Rayhan wrote:
> > > >
> > > > > I believe there is an agreement that commands are
> atomic, either
> > > > > succeed or fail and no partial commands. but I agree
> with you that
> > > > > there is no text, up to my knowledge, saying that
> descriptors are
> > > > > attempted in order. The closest  we get to this is in
> Section 8,
> > > > > "Transactions guarantee ordered Command processing.
> That is, Commands
> > > > > within a Transaction are executed sequentially. Ordering of
> > > Transactions is
> > > > > NOT guaranteed - transactions may be executed in any order, or
> > > > > simultaneously."
> > > > >
> > > > > I propose adding the following sentence to the above
> paragraph,
> > > > > " All commands are atomic operations, either succeed
> or fail as a whole,
> > > > > and descriptors within commands are processed in
> sequence of their
> > > > > order."
> > > > >
> > > > > Abdallah Rayhan
> > > > >
> > > > > Chip Sharp wrote:
> > > > >
> > > > > > Due to a previous question on event handling, I
> went through the
> > > output of
> > > > > > However, I could find no text in the document that
> describes in
> > > what order
> > > > > > TerminationStateDescriptor and the EventsDescriptor
> will affect how
> > > events
> > > > > > EventBuffer is flushed (ignoring the previous
> discussion as to
> > > whether this
> > > > > > is desirable or not).
> > > > > >
> > > > > > It seems there may be any number of conditions like
> this that will
> > > depend
> > > > > > received or that the receiver can process them in
> any order desired?  I
> > > > > > If there is already text of this nature in the
> document, please
> > > educate me
> > > > > > as to its location.
> > > > > >
> > > > > > Thanks,
> > > > > > Chip

---

From: Hemant <[email-masked]>
Date: Fri, 24 Mar 2000 17:00:54 +0530

Hi,

     I wish to have some clarification on the issue of command being atomic.
Does this imply that if an activity has been initiated by the MG in response to a command and subsequently a failure occurs during its processing, the MG should rollback all actions that have happened till that point in the command (in which error has occurred).

For e.g.
- The MG is looking for some Events on a particular termination
- A modify command containing another event desc. and signal desc. is received for that termination (Descriptors in that order)
- The events are configured in the MG ( acc. to the new event desc.)
- Error is encountered in the MG while allocation of the resources for generating signals
- Rollback implies that the MG stop looking the current event and again start looking for the initial events.

If rollback is what the protocol implies than there will be more complications if embedded commands were to be treated as atomic.

Regards,
Hemant

------------------------------------------------
Hemant Kumar
Ficon Technology
E-mail: mailto:[email-masked]
Web: http://www.ficon-tech.com
------------------------------------------------

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 24 Mar 2000 07:56:40 -0500

Hemant

Yes, it implies rollback, although I wouldn't implement it that way (I'd
allocate all the resources, then make the state changes).

At some point, you have a balance between discriminating errors and ease of
implementation, as well as one between the complexity of the syntax and ease
of
implementation.

If we were to say that the descriptors are executed in order, and errors can
occur
at any descriptor, then what about your example where the signals descriptor
contains
two signals, the first is okay, but the second fails?  Should we remove the
first?
That's atomicity of descriptors.  Should we allow sequential execution of
elements
in a descriptor or force "rollback" within the descriptor?

Please do keep in mind that I advocated atomicity of transactions, and was
in a
distinct minority.

Brian

-----Original Message-----
From: Hemant [mailto:[email-masked]]
Sent: Friday, March 24, 2000 6:31 AM
To: [email-masked]
Subject: Re: Descriptor processing order

Hi,

     I wish to have some clarification on the issue of command being atomic.
Does this imply that if an activity has been initiated by the MG in response
to a command and subsequently a failure occurs during its processing, the MG
should rollback all actions that have happened till that point in the
command (in which error has occurred).

For e.g.
- The MG is looking for some Events on a particular termination
- A modify command containing another event desc. and signal desc. is
received for that termination (Descriptors in that order)
- The events are configured in the MG ( acc. to the new event desc.)
- Error is encountered in the MG while allocation of the resources for
generating signals
- Rollback implies that the MG stop looking the current event and again
start looking for the initial events.

If rollback is what the protocol implies than there will be more
complications if embedded commands were to be treated as atomic.

Regards,
Hemant

------------------------------------------------
Hemant Kumar
Ficon Technology
E-mail: mailto:[email-masked] <mailto:[email-masked]>
Web: http://www.ficon-tech.com <http://www.ficon-tech.com>
------------------------------------------------