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

15 Dec 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%...

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@nortel.com> -----
    Date: Fri, 2 Dec 2005 10:06:14 -0500
    From: Kevin Boyle <kboyle@nortel.com>
Reply-To: Kevin Boyle <kboyle@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@ties.itu.ch, Yangbo Lin <linyangbo@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@ties.itu.ch [mailto:albrecht.schwarz@ties.itu.ch]

Sent: Friday, December 02, 2005 10:03 AM
To: Yangbo Lin
Cc: albrecht.schwarz@ties.itu.ch; Boyle, Kevin [NCRTP:3Z40:EXCH];
albrecht.schwarz@ties.itu.ch; geoff.hunt@bt.com;
arturo.martin-de-nicolas@ericsson.com; cdahm@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.
...
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@ties.itu.int
  To: Kevin Boyle
  Cc: Yangbo Lin ; albrecht.schwarz@ties.itu.ch ; geoff.hunt@bt.com ;
arturo.martin-de-nicolas@ericsson.com ; cdahm@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@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
Albrecht

Quoting Yangbo Lin <linyangbo@huawei.com>:

the MG
...
...
is currently undefined in the spec.
Kevin
________________________________
From: Yangbo Lin [mailto:linyangbo@huawei.com]
Sent: Friday, December 02, 2005 9:11 AM
To: Boyle, Kevin [NCRTP:3Z40:EXCH]; albrecht.schwarz@ties.itu.ch
Cc: geoff.hunt@bt.com; albrecht.schwarz@ties.itu.ch;
arturo.martin-de-nicolas@ericsson.com; cdahm@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@nortel.com>
To: Yangbo Lin <mailto:linyangbo@huawei.com>  ;
albrecht.schwarz@ties.itu.ch
Cc: geoff.hunt@bt.com ; albrecht.schwarz@ties.itu.ch ;
arturo.martin-de-nicolas@ericsson.com ; cdahm@cisco.com ;
Christian
Groves <mailto:cngroves@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@huawei.com]
Sent: Friday, December 02, 2005 8:45 AM
To: albrecht.schwarz@ties.itu.ch; Boyle, Kevin
[NCRTP:3Z40:EXCH]
Cc: geoff.hunt@bt.com;
albrecht.schwarz@ties.itu.ch;
arturo.martin-de-nicolas@ericsson.com;
cdahm@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@ties.itu.int
<mailto:albrecht.schwarz@ties.itu.int>
To: Kevin Boyle
<mailto:kboyle@nortel.com>
Cc: geoff.hunt@bt.com
<mailto:geoff.hunt@bt.com>  ; linyangbo@huawei.com
<mailto:linyangbo@huawei.com>  ; albrecht.schwarz@ties.itu.ch
<mailto:albrecht.schwarz@ties.itu.ch>  ;
arturo.martin-de-nicolas@ericsson.com
<mailto:arturo.martin-de-nicolas@ericsson.com>  ; cdahm@cisco.com
<mailto:cdahm@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@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@bt.com
[mailto:geoff.hunt@bt.com]
Sent: Friday, December 02, 2005 6:40
AM
To: linyangbo@huawei.com; Boyle, Kevin
[NCRTP:3Z40:EXCH];
albrecht.schwarz@ties.itu.ch
Cc:
arturo.martin-de-nicolas@ericsson.com; cdahm@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@huawei.com]
Sent: 02 December 2005 11:28
To: Kevin Boyle;
albrecht.schwarz@ties.itu.ch
Cc:
arturo.martin-de-nicolas@ericsson.com; Hunt,RG,Geoff,XDE81
R; cdahm@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@nortel.com>
To: albrecht.schwarz@ties.itu.ch
<mailto:albrecht.schwarz@ties.itu.ch>
; Yangbo Lin
<mailto:linyangbo@huawei.com>
Cc:
arturo.martin-de-nicolas@ericsson.com
...
<mailto:geoff.hunt@bt.com>  ;
cdahm@cisco.com <mailto:cdahm@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@ties.itu.ch
[mailto:albrecht.schwarz@ties.itu.ch]
Sent: Friday, December 02, 2005 6:03
AM
To: Yangbo Lin
Cc: albrecht.schwarz@ties.itu.ch;
Boyle, Kevin
[NCRTP:3Z40:EXCH];
albrecht.schwarz@ties.itu.ch;
arturo.martin-de-nicolas@ericsson.com;
geoff.hunt@bt.com; cdahm@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
...
fairly flexible
usage of the Statistics Descriptor.
Some examples may
illustrate some
use use cases.
Quoting Yangbo Lin
<linyangbo@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@ties.itu.int
  To: Kevin Boyle
  Cc: albrecht.schwarz@ties.itu.ch ;
linyangbo@huawei.com ;
arturo.martin-de-nicolas@ericsson.com ;
geoff.hunt@bt.com ;
...
cdahm@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,
...
...
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@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,
...
...
resetting the included
statistics.  By bundling
propose to
this has the
effect of
the two commands
...
...
together into the same action or
...
...
...
time during which statistics are
not collected by
MGC can minimize
the
the MG.
...
...
If this looks OK, I will alter
...
it as 46a.
...
...
Kevin
-----Original Message-----
From:
albrecht.schwarz@ties.itu.ch
...
...
Sent: Friday, December 02, 2005
4:24 AM
...
To: Boyle, Kevin
[NCRTP:3Z40:EXCH]
Cc:
albrecht.schwarz@ties.itu.ch;
[mailto:albrecht.schwarz@ties.itu.ch]
linyangbo@huawei.com;
...
...
arturo.martin-de-nicolas@ericsson.com;
geoff.hunt@bt.com;
...
cdahm@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@ties.itu.int:
...
Kevin,
pls find attached comments to
"6.4 Clarification of
statistic reset
capability".
Like to offer following change
<mailto:arturo.martin-de-nicolas@ericsson.com>  ;
geoff.hunt@bt.com
protocol allows a
then I'd like to
transaction, the
the IG and upload
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 -----

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

Albrecht.Schwarz＠alcatel.de

tags

participants (1)