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.
Albrecht
Quoting Yangbo Lin linyangbo@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@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
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
To: albrecht.schwarz@ties.itu.ch mailto:albrecht.schwarz@ties.itu.ch
; Yangbo Lin
arturo.martin-de-nicolas@ericsson.com
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
protocol allows a
fairly flexible usage of the Statistics Descriptor.
Some examples may
illustrate some use use cases.
Quoting Yangbo Lin
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,
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
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@ties.itu.ch
[mailto: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;
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
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 -----