H.248.1 - Examples for the Usage of the Statistics Descriptor

Albrecht.Schwarz at alcatel.de Albrecht.Schwarz at alcatel.de
Thu Dec 15 08:28:00 EST 2005


Dear All!

With regards to our discussions last WP2/16 meeting and:
> This is why I believe contributions are needed to April's meeting.

I'd like to inform you that we drafted a contribution with a first
proposal:

See in
http://ftp3.itu.int/av-arch/avc-site/Incoming/

file:

http://ftp3.itu.int/av-arch/avc-site/Incoming/Alcatelt1%20T05-SG16-060403-D%20H.248.1%20StatisticsDescriptorEd03.doc

After intensive studies of § 7.1.15 we did finally come to the conclusion
what a new Appendix for H.248.1 on"Practices on Statistics ? Exemplary Use
Cases" could be one way forward.

Comments?
Albrecht

PS
Yangbo,
the specific capability you are looking for is in IV.5.7


----- Forwarded message from Kevin Boyle <kboyle at nortel.com> -----
    Date: Fri, 2 Dec 2005 10:06:14 -0500
    From: Kevin Boyle <kboyle at nortel.com>
Reply-To: Kevin Boyle <kboyle at nortel.com>
 Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4
Clarification of statistic reset capability
      To: albrecht.schwarz at ties.itu.ch, Yangbo Lin <linyangbo at huawei.com>

There is certainly no *documented* capability in H.248 to allow the MGC
to assign a value to a statistic.  This is why I believe contributions
are needed to April's meeting.

Kevin

-----Original Message-----
From: albrecht.schwarz at ties.itu.ch [mailto:albrecht.schwarz at ties.itu.ch]

Sent: Friday, December 02, 2005 10:03 AM
To: Yangbo Lin
Cc: albrecht.schwarz at ties.itu.ch; Boyle, Kevin [NCRTP:3Z40:EXCH];
albrecht.schwarz at ties.itu.ch; geoff.hunt at bt.com;
arturo.martin-de-nicolas at ericsson.com; cdahm at cisco.com; Christian Groves
Subject: Re: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4
Clarification of statistic reset capability

Firstly, the MGC as master and "prime served user" for H.248 statistics
may perform any operation(as defined by H.248) on statistics.

Secondly:
>This capability is not in the existing protocol.
I think that all outlined scenarios in these emails are syntactically,
and even semantically in line with H.248.1.
Could find sth against it in the spec.

Albrecht


Quoting Yangbo Lin <linyangbo at huawei.com>:

> In my understanding, the statistic only operated by the MG, and the
> MGC can only disable or enable it. This setting the statistic to zero
> actually give the MGC the capability to interrupt the operation of
> statistic arbitrarily as it will. This capability is not in the
existing protocol.
>
>   ----- Original Message -----
>   From: albrecht.schwarz at ties.itu.int
>   To: Kevin Boyle
>   Cc: Yangbo Lin ; albrecht.schwarz at ties.itu.ch ; geoff.hunt at bt.com ;
> arturo.martin-de-nicolas at ericsson.com ; cdahm at cisco.com ; Christian
Groves
>   Sent: Friday, December 02, 2005 3:30 PM
>   Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4
> Clarification of statistic reset capability
>
>
>   Yangbo,
>   any "reset" operation comes finally down to the defined "data type"
> and "value
>   range" of a dedicated statistic.
>   Reset means setting to the "initial value".
>   The initial value in the context of statistics is typically either
>   a) value = 0, or
>   b) value = 'unknown' (e.g., certain VoIP metrics).
>
>   Of course the name/value combination in the context of a desired
> reset operation
>   makes perhaps only sense for case (a), and I'm fairly sure, is only
> required for
>   case (a).
>   But I will check out also potential metrics of type (b).
>
>   Albrecht
>
>   PS
>   Do you have already a specific statistic of type (b) in mind?
>
>
>   Quoting Kevin Boyle <kboyle at nortel.com>:
>
>   > The intent is that the statistic will be explicitly set to 0.  Of
>   > course, other statistics may need to be reset to some other
default
>   > value.  This puts the onus on the MGC to know what the "reset
value" of
>   > all supported statistics are.
>   >
>   > So, the "0" is not a flag, it is a value.  There is no exceptional
>   > request here.  This syntax is legal, but the way to handle it in
the MG
>   > is currently undefined in the spec.
>   >
>   > Kevin
>   >
>   >
>   > ________________________________
>   >
>   > From: Yangbo Lin [mailto:linyangbo at huawei.com]
>   > Sent: Friday, December 02, 2005 9:11 AM
>   > To: Boyle, Kevin [NCRTP:3Z40:EXCH]; albrecht.schwarz at ties.itu.ch
>   > Cc: geoff.hunt at bt.com; albrecht.schwarz at ties.itu.ch;
>   > arturo.martin-de-nicolas at ericsson.com; cdahm at cisco.com; Christian
> Groves
>   > Subject: Re: 1 Comm. with 2 Descr.;RE: Attach; Re: TD-46-1 6.4
>   > Clarification of statistic reset capability
>   >
>   >
>   > Maybe I misunderstand, you mean the "SA{pkg/stat1=0}" represents
>   > the resetting? Is the "0" a reset flag or only a value? Does it
request
>   > the MG to deal with the "0" exceptionally? Moreover, what will
> happen if
>   > the "0" is a valid value of the parameter and no resetting value?
>   >
>   >
>   > ----- Original Message -----
>   > From: Kevin Boyle <mailto:kboyle at nortel.com>
>   > To: Yangbo Lin <mailto:linyangbo at huawei.com>  ;
>   > albrecht.schwarz at ties.itu.ch
>   > Cc: geoff.hunt at bt.com ; albrecht.schwarz at ties.itu.ch ;
>   > arturo.martin-de-nicolas at ericsson.com ; cdahm at cisco.com ;
Christian
>   > Groves <mailto:cngroves at bigpond.net.au>
>   > Sent: Friday, December 02, 2005 2:51 PM
>   > Subject: RE: 1 Comm. with 2 Descr.;RE: Attach; Re:
>   > TD-46-1 6.4 Clarification of statistic reset capability
>   >
>   > The concept would look like this:(assume pkg/stat1 and
>   > pkg/stat2)
>   >
>   > !/3 [12.34.56.78]:2944
>   > T=123{C=12{MF=term1{AT{SA{pkg/stat1}},SA{pkg/stat1=0,pkg/stat2}}}}
>   >
>   > This would lead to the following response:
>   >
>   > !/3 [12.34.56.79]:2944
>   > P=123{C=12{MF=term1{pkg/stat1=123}}}
>   >
>   > Because this behavior is currently undocumented in the
>   > spec, this will require a contribution to Q3 in April.  Albrecht
has
>   > agreed to bring such a contribution.
>   >
>   > Kevin
>   >
>   >
>   > ________________________________
>   >
>   > From: Yangbo Lin [mailto:linyangbo at huawei.com]
>   > Sent: Friday, December 02, 2005 8:45 AM
>   > To: albrecht.schwarz at ties.itu.ch; Boyle, Kevin
>   > [NCRTP:3Z40:EXCH]
>   > Cc: geoff.hunt at bt.com;
>   > albrecht.schwarz at ties.itu.ch;
arturo.martin-de-nicolas at ericsson.com;
>   > cdahm at cisco.com
>   > Subject: Re: 1 Comm. with 2 Descr.;RE: Attach;
>   > Re: TD-46-1 6.4 Clarification of statistic reset capability
>   >
>   >
>   > Do you mean that a Modify command with three
>   > descriptors, i.e. Audit Descriptor (for read), Statistics
Descriptor
>   > excluding the statistic (for disable and remain) and Statistics
>   > Descriptor including the statistic (for re-enable and reset) in
order?
>   > Is it valid in protocol about including two Statistics Descriptors
in
>   > one command?
>   >
>   >
>   > ----- Original Message -----
>   > From: albrecht.schwarz at ties.itu.int
>   > <mailto:albrecht.schwarz at ties.itu.int>
>   > To: Kevin Boyle
>   > <mailto:kboyle at nortel.com>
>   > Cc: geoff.hunt at bt.com
>   > <mailto:geoff.hunt at bt.com>  ; linyangbo at huawei.com
>   > <mailto:linyangbo at huawei.com>  ; albrecht.schwarz at ties.itu.ch
>   > <mailto:albrecht.schwarz at ties.itu.ch>  ;
>   > arturo.martin-de-nicolas at ericsson.com
>   > <mailto:arturo.martin-de-nicolas at ericsson.com>  ; cdahm at cisco.com
>   > <mailto:cdahm at cisco.com>
>   > Sent: Friday, December 02, 2005 1:53 PM
>   > Subject: 1 Comm. with 2 Descr.;RE:
>   > Attach; Re: TD-46-1 6.4 Clarification of statistic reset
capability
>   >
>   >
>   > We did discuss a potential improvement
>   > over lunch:
>   >
>   > 1 Modify Command with an Audit
>   > Descriptor (for read) & Statistics Descriptor
>   > (for reset)
>   >
>   > This solution is syntactically correct,
>   > requires only a single H.248 Command,
>   > and ensure processing in order.
>   >
>   > I'll bring a correspondent contribution
>   > to next meeting for updating IMGs (V2 & V3).
>   >
>   > - Albrecht
>   >
>   > Quoting Kevin Boyle <kboyle at nortel.com>:
>   >
>   > > While I think that is a valid
>   > optimization, I am not sure we can place
>   > > it in the protocol spec.  The spec
>   > already goes out of its way to
>   > > require that transactions, actions and
>   > commands are executed in order.
>   > > Given this, I am not sure that we can
>   > put text in that allows an
>   > > explicit exception for this operation.
>   > >
>   > > This then becomes an implementation
>   > detail.  As far as I am concerned,
>   > > as long as the MG executes the
>   > commands (in this case, report the stat
>   > > and clear it) it does not really
>   > matter whether that is done one command
>   > > at a time or in an optimized
>   > "one-step" fashion.
>   > >
>   > > Kevin
>   > >
>   > >
>   > > ________________________________
>   > >
>   > > From: geoff.hunt at bt.com
>   > [mailto:geoff.hunt at bt.com]
>   > > Sent: Friday, December 02, 2005 6:40
>   > AM
>   > > To: linyangbo at huawei.com; Boyle, Kevin
>   > [NCRTP:3Z40:EXCH];
>   > > albrecht.schwarz at ties.itu.ch
>   > > Cc:
>   > arturo.martin-de-nicolas at ericsson.com; cdahm at cisco.com
>   > > Subject: RE: Attach; Re: TD-46-1 6.4
>   > Clarification of statistic
>   > > reset capability
>   > >
>   > >
>   > > Is it possible to recommend that a
>   > gateway which *can* do
>   > > lookahead across the commands in a
>   > transaction, and sees read-and-reset
>   > > commands combined like this, *should*
>   > do the read-and-reset atomically?
>   > > This could ensure that no value which
>   > should contribute to the statistic
>   > > is lost between read and reset.
>   > >
>   > > I'm sorry I don't understand H.248 in
>   > enough depth and detail to
>   > > know whether there is any fundamental
>   > objection to this :(
>   > >
>   > > ________________________________
>   > >
>   > > From: Yangbo Lin
>   > [mailto:linyangbo at huawei.com]
>   > > Sent: 02 December 2005 11:28
>   > > To: Kevin Boyle;
>   > albrecht.schwarz at ties.itu.ch
>   > > Cc:
>   > arturo.martin-de-nicolas at ericsson.com; Hunt,RG,Geoff,XDE81
>   > > R; cdahm at cisco.com
>   > > Subject: Re: Attach; Re: TD-46-1 6.4
>   > Clarification of statistic
>   > > reset capability
>   > >
>   > >
>   > > OK, I just ignored this more efficient
>   > way, then we have a great
>   > > idea and a good example. Now the only
>   > leaving problem is how to avoid
>   > > the lost about the extreme value
>   > between the two command. I hope we can
>   > > discuss and resolve it in Q3 as early
>   > as possible.
>   > >
>   > >
>   > > ----- Original Message -----
>   > > From: Kevin Boyle
>   > <mailto:kboyle at nortel.com>
>   > > To: albrecht.schwarz at ties.itu.ch
>   > > <mailto:albrecht.schwarz at ties.itu.ch>
>   > ; Yangbo Lin
>   > > <mailto:linyangbo at huawei.com>
>   > > Cc:
>   > arturo.martin-de-nicolas at ericsson.com
>   > >
>   > <mailto:arturo.martin-de-nicolas at ericsson.com>  ;
geoff.hunt at bt.com
>   > > <mailto:geoff.hunt at bt.com>  ;
>   > cdahm at cisco.com <mailto:cdahm at cisco.com>
>   > > Sent: Friday, December 02, 2005 12:05
>   > PM
>   > > Subject: RE: Attach; Re: TD-46-1 6.4
>   > Clarification of
>   > > statistic reset capability
>   > >
>   > > I think this is a great idea.  I look
>   > forward to your
>   > > contribution in
>   > > April.  Maybe you can use the example
>   > I cooked up in my
>   > > earlier email as
>   > > a start! ;)
>   > >
>   > > Kevin
>   > >
>   > > -----Original Message-----
>   > > From: albrecht.schwarz at ties.itu.ch
>   > > [mailto:albrecht.schwarz at ties.itu.ch]
>   > >
>   > > Sent: Friday, December 02, 2005 6:03
>   > AM
>   > > To: Yangbo Lin
>   > > Cc: albrecht.schwarz at ties.itu.ch;
>   > Boyle, Kevin
>   > > [NCRTP:3Z40:EXCH];
>   > > albrecht.schwarz at ties.itu.ch;
>   > > arturo.martin-de-nicolas at ericsson.com;
>   > > geoff.hunt at bt.com; cdahm at cisco.com
>   > > Subject: Re: Attach; Re: TD-46-1 6.4
>   > Clarification of
>   > > statistic reset
>   > > capability
>   > >
>   > > See previous eamils.
>   > >
>   > > Nevertheless, there is a demand for
>   > examples in order to
>   > > illustrate the
>   > > application of the Statistics
>   > Descriptor capabilities.
>   > > Just the note that I'll draft some
>   > examples for next
>   > > meeting.
>   > >
>   > > Albrecht
>   > > PS
>   > > My motivation is that I think that the
>   > Statistics
>   > > Descriptor is a fairly
>   > > powerful tool due to:
>   > >
>   > > The Statistics Descriptor may contain,
>   > according syntax
>   > > specifications
>   > > in Annex A and Annex B of H.248.1,
>   > either * an empty
>   > > list ("empty
>   > > Statistics Descriptor"), or * an
>   > explicit list of
>   > > name/value pairs [NVP;
>   > > (statistic name)/(statistic value);
>   > statistic name is
>   > > defined by
>   > > PackageID/StatisticID], or * an
>   > explicit list of
>   > > statistic names without
>   > > correspondent values (note:
>   > > statistic value is optional), or
>   > > * an explicit list of names and
>   > name/value combinations.
>   > > This syntactical definition of the
>   > protocol allows a
>   > > fairly flexible
>   > > usage of the Statistics Descriptor.
>   > Some examples may
>   > > illustrate some
>   > > use use cases.
>   > >
>   > >
>   > >
>   > > Quoting Yangbo Lin
>   > <linyangbo at huawei.com>:
>   > >
>   > > > How can we perform read and/or
>   > disable in one command?
>   > > The statistic
>   > > > included in the descriptor means it
>   > should be read,
>   > > and the statistic
>   > > > excluded from the descriptor means
>   > it should be
>   > > disable. This seems a
>   > > > conflict. So the read, disable and
>   > re-enable need
>   > > three commands, it
>   > > > is too inefficient and do not
>   > resolve problem,
>   > > especially for the
>   > > > extreme parameter. It is just the
>   > cause we proposed
>   > > the universal
>   > > > resetting mechanism which want to
>   > resolve the problem
>   > > in one command.
>   > > >
>   > > >   ----- Original Message -----
>   > > >   From:
>   > albrecht.schwarz at ties.itu.int
>   > > >   To: Kevin Boyle
>   > > >   Cc: albrecht.schwarz at ties.itu.ch ;
>   > > linyangbo at huawei.com ;
>   > > >
>   > arturo.martin-de-nicolas at ericsson.com ;
>   > > geoff.hunt at bt.com ;
>   > > > cdahm at cisco.com
>   > > >
>   > > >   Sent: Friday, December 02, 2005
>   > 11:17 AM
>   > > >   Subject: RE: Attach; Re: TD-46-1
>   > 6.4 Clarification
>   > > of statistic
>   > > > reset capability
>   > > >
>   > > >
>   > > >   I think
>   > > >   * we should be explicit that the
>   > 1st Modify
>   > > inherently supports
>   > > > "Statistic read"
>   > > >   operation, in addition to the
>   > "disable operation",
>   > > >
>   > > >   and if this is true
>   > > >   * an additional AuditValue prior
>   > to the first Modify
>   > > is thus not
>   > > > required.
>   > > >
>   > > >   The assumption is that a dedicated
>   > Statistics
>   > > Descriptor setting in
>   > > > the 1st
>   > > >   Modify allows "read and/or
>   > disable" in one step.
>   > > >   My second assumption is, that the
>   > 1st Modify may be
>   > > replace by
>   > > > AuditValue to get
>   > > >    adequate "read and/or disable"
>   > operations in one
>   > > step.
>   > > >
>   > > >   If my understanding is correct,
>   > then I'd like to
>   > > propose to
>   > > >   a) replace "to disable" by " to
>   > read and/or to
>   > > disable", and
>   > > >   b) replace "the MGC may send a
>   > Modify ..." by "the
>   > > MGC may send a
>   > > > Modify or
>   > > >   AuditValue ..."
>   > > >
>   > > >   Albrecht
>   > > >
>   > > >
>   > > >
>   > > >
>   > > >
>   > > >   Quoting Kevin Boyle
>   > <kboyle at nortel.com>:
>   > > >
>   > > >   > I like the points raised by your
>   > suggested text.
>   > > How about this:
>   > > >   >
>   > > >   > For terminations not in the NULL
>   > Context, the MGC
>   > > may send a
>   > > Modify
>   > > >   > Command with a Statistics
>   > Descriptor to disable
>   > > one or more
>   > > statistics
>   > > >   > followed by a second Modify
>   > Command including a
>   > > Statistics
>   > > > Descriptor to
>   > > >   > re-enable those statistics.  As
>   > explained above,
>   > > this has the
>   > > effect of
>   > > >   > resetting the included
>   > statistics.  By bundling
>   > > the two commands
>   > > >   > together into the same action or
>   > transaction, the
>   > > MGC can minimize
>   > > the
>   > > >   > time during which statistics are
>   > not collected by
>   > > the MG.
>   > > >   >
>   > > >   > If this looks OK, I will alter
>   > the IG and upload
>   > > it as 46a.
>   > > >   >
>   > > >   > Kevin
>   > > >   >
>   > > >   > -----Original Message-----
>   > > >   > From:
>   > albrecht.schwarz at ties.itu.ch
>   > > >
>   > [mailto:albrecht.schwarz at ties.itu.ch]
>   > > >   >
>   > > >   > Sent: Friday, December 02, 2005
>   > 4:24 AM
>   > > >   > To: Boyle, Kevin
>   > [NCRTP:3Z40:EXCH]
>   > > >   > Cc:
>   > albrecht.schwarz at ties.itu.ch;
>   > > linyangbo at huawei.com;
>   > > >   >
>   > arturo.martin-de-nicolas at ericsson.com;
>   > > geoff.hunt at bt.com;
>   > > >   > cdahm at cisco.com
>   > > >   > Subject: Attach; Re: TD-46-1 6.4
>   > Clarification of
>   > > statistic reset
>   > > >   > capability
>   > > >   >
>   > > >   > Not sure whether attachment was
>   > delivered.
>   > > >   > Again ...
>   > > >   >
>   > > >   >
>   > > >   > Quoting
>   > albrecht.schwarz at ties.itu.int:
>   > > >   >
>   > > >   > > Kevin,
>   > > >   > >
>   > > >   > > pls find attached comments to
>   > > >   > > "6.4 Clarification of
>   > statistic reset
>   > > capability".
>   > > >   > >
>   > > >   > > Like to offer following change
>   > proposals:
>   > > >   > > - "prior to Subtract" (of
>   > course it's
>   > > semantically correct)
>   > > >   > > - add AuditValue,
>   > > >   > > - add one or two Notes in
>   > order to incate
>   > > Statistic Descriptor
>   > > > details
>   > > >   >
>   > > >   > > (this is important usage
>   > information IMHO)
>   > > >   > >
>   > > >   > > Albrecht
>   > > >   >
>   > > >   >
>   > > >   >
>   > > >   >
>   > > >
>   > > >
>   > > >
>   > >
>   > >
>   > >
>   > >
>   > >
>   > >
>   >
>   >
>   >
>   >
>   >
>
>
>






----- End forwarded message -----






More information about the sg16-avd mailing list