Subject: Re: Statistics

From: Brian Rosen <[email-masked]>
Date: Tue, 7 Sep 1999 15:13:32 -0400

Does anyone object to this?
        RequestedInfo is allowed in Add/Subtract/Move/Modify
        If it occurs, the requested descriptor is
                returned with the command as with AuditValue

As an aside.  AuditValue can now be considered a No-Op
which permits RequestedInfo.  If we need a no-op for other
reasons, this can be it.

Can I hear opinions on whether:
        Subtract does NOT automatically return statistics,
                RequestedInfo is used to ask for them
or, my personal favorite
        There is a property of root which turns on or off
                the automatic generation of statistics from
                subtract and another for move

Brian

> -----Original Message-----
> From: Nancy-M Greene [mailto:[email-masked]]
> Sent: Tuesday, September 07, 1999 11:31 AM
> To: [email-masked]; 'Brian Rosen'
> Subject: RE: Statistics
>
>
> Brian, you are right, RequestedInfo can be used in the same way I was
> thinking of using a flag. So, on further thought, it would
> make sense to
> allow RequestedInfo in Subtract, and perhaps also in Add,
> Move, and Modify.
>
> Nancy
> --------------------------------------------------------------
> ------------
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
>
> > ----------
> > From:       Brian Rosen[SMTP:[email-masked]]
> > Sent:       Friday, September 03, 1999 10:20 AM
> > To:         [email-masked]
> > Subject:    Re: Statistics
> >
> > I do think we are into feature-creep here, and I do
> > want to stop it.
> >
> > I don't agree that having RequestedInfo legal in other
> commands makes
> > implementation more complicated.  Commands need to be able
> to return all
> > sorts of descriptors if there was an underspecified
> parameter included.
> > Processing the requestedInfo descriptor has to be there for
> AuditValue
> > anyway.  I suspect it is close to zero work to make it
> > happen; probably much more work to test it than to implement it.
> >
> > What kind of "flag" were you thinking?  If it's in the
> command, then the
> > only flag that makes sense is "RequestedInfo".  If it's my
> > property-of-root,
> > then
> > I'll agree it's a good idea, but why wouldn't you have
> > the same thing for Move?
> >
> > Brian
> >
> >
>

---

From: Rex Coldren <[email-masked]>
Date: Tue, 7 Sep 1999 15:59:28 -0700

Brian,
I like the following:

There is a property of root which turns on or off automatic
generation of statistics from subtract (would we really want
to automatically do this on a move?).  If this property is not
set then RequestedInfo is used to ask for statistics.

Rex

---

From: Michael Thomas <[email-masked]>
Date: Tue, 7 Sep 1999 17:33:15 -0700

> set then RequestedInfo is used to ask for statistics.

   Hmm. The entire concept of root variables sure
   sounds like a slippery slope to provisioning if
   you ask me. At some point it's probably better
   to handle such things outside of MEGACO,
   probably in a MIB.

               Mike

---

From: Rex Coldren <[email-masked]>
Date: Tue, 7 Sep 1999 19:05:35 -0700

Mike,
   Good point.  I agree.

Rex

---

From: Abdallah Rayhan <[email-masked]>
Date: Wed, 8 Sep 1999 11:27:40 -0400

Should we allow global flags that we could set on and off for
particular commands ? Is this a MEGACO way of doing things ?
I dont think so. Otherwise, why would we have all these commands
and descriptors !

Should we allow stats request in certain commands ? We started
with specialized commands to perform exclusive functionality and
now we are making them inclusive. Are we going ever to draw the
line on this version ?

I believe that the real problem is not the stats but we have not defined
how changes are committed within an action, e.g., when the commands
are processed, are they executed at the same instant similar to banking
transactions ? This does not change the commands order because we
can always time it as action execution time. If that is the case, then we obtain

stats by issuing an AuditValue command before Add/Move/Modify/Substract.

The syntax issue could be nothing but semantics in this case !

If we dont put any constraints on commands execution, this could
introduce chaos, e.g., long delay between two commands results
in command failure !

In either case, if a decision is made to request certain audit values with
some commands, then we need something like auditDescriptor that specifies
which values should be returned. requestedInfoDescriptor is very general
and we dont need all but stats only.

Abdallah Rayhan

---

From: Christian Huitema <[email-masked]>
Date: Thu, 9 Sep 1999 09:49:19 -0400

>set then RequestedInfo is used to ask for statistics.

No, please don't do that! This is a 'side effect' construct, where a past
command changes the behavior of ulterior commands. Such constructs are a
known receipe for problems, e.g. if 2 MGC control the same gateway. I would
much rather have a flag in every substract operation.

Also please note that statistics have to be sent with the substract.
Termination disappear after substract, which means that there won't be any
chance to do an audit. Doing the audit before the substract would introduce
a time delay, and a period of uncertainty.
-- Christian Huitema