Subject: Re: Statistics

From: Brian Rosen <[email-masked]>
Date: Wed, 8 Sep 1999 16:24:46 -0400

As I just stated, I'd prefer to use RequestedInfo.

The flag is optional, it's just a convenience and bit
saver if the MGC always wants stats for every Subtract
(or every Move).

While having requestedInfo in Add/Move/Modify/Subtract does
indeed lessen the importance of AuditValue, it doesn't
eliminate it.  I see no problems.

Brian

> -----Original Message-----
> From: Nancy-M Greene [mailto:[email-masked]]
> Sent: Wednesday, September 08, 1999 12:30 PM
> To: [email-masked]
> Subject: Re: Statistics
>
>
> So, to summarize
>
> - we allow stats to be requested on Add, Move, Modify, and
> Subtract - need a
> RequestStatsToken
> - we do NOT need to allow anything to be requested on these
> commands - leave
> that job to AuditValue, so leave RequestedInfo as a parameter
> to AuditValue
> only
>
> Reasoning:
> We could put an AuditValue and an Subtract in the same
> transaction, but
> there may be latency between the execution of one and the
> execution of the
> other, especially if both have a wildcard as a terminationID.
>
> In fact words to this effect need to be added to the
> transaction section.
> Proposed text:
> "The execution of commands in an action, and actions in a
> transaction, are
> not assumed to happen at the same instant."
>
> Thus, to ensure that stats are accurate, we want to be able
> to return them
> upon execution of certain commands (Add, Move, Modify, Subtract).
>
> Adding a way to request stats to the above commands is
> sufficient - adding
> more would give us commands that can do everything, and this
> defeats the
> purpose of having different commands in the first place.
>
> Nancy
> .
>         Abdallah Rayhan writes:
>         <snip>
> > 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
> >
> >
> > Brian Rosen wrote:
> >
> > > 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
> >
> --------------------------------------------------------------
> ------------
> Nancy M. Greene
> Internet & Service Provider Networks, Nortel Networks
> T:514-271-7221 (internal:ESN853-1077) E:[email-masked]
>