Subject: Re: Statistics

From: Brian Rosen <[email-masked]>
Date: Thu, 9 Sep 1999 17:58:37 -0400

I understand your reluctance to avoid side effect commands.
I think there is some state in the MG that the MGC can modify.
That is a side effect.  This would indeed be another such case.
Expanding to multiple MGCs controlling an MG would be straightforward
for such a parameter as it would be MGC sensitive (state per controlling
MGC).

I'm not pushing hard for the option, I do observe that statistics can
be lengthy, and some degree of control by the MGC is desirable.

Also note that the proposal is to allow RequestedInfo in the Subtract
(or Move, or Modify, or even Add).  The simple case is
RequestedInfo(Statistics), which would return statistics as a return
parameter from the command it was invoked in.  So
       Subtract=*{RequestedInfo{Statistics}}
would do what we now define default behavior to do.  This will have the
correct effect of returning statistics on the Subtract, but at MGC
request instead of automatically.

The observation that prompted this suggestion is whether Move should
always return statistics as Subtract is now specified to do.  The
sentiment I get is no, not always.  This lead me to the suggestion
that it was easy to make it a requestable item.  The flag was to
supply a shorthand convenience.  It isn't necessary, just convenient.

Brian

> -----Original Message-----
> From: Christian Huitema [mailto:[email-masked]]
> Sent: Thursday, September 09, 1999 9:49 AM
> To: [email-masked]
> Subject: Re: Statistics
>
>
> At 03:59 PM 9/7/99 -0700, Rex Coldren wrote:
> >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.
>
> 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
>