Re: H.248.1 - Examples for the Usage of the Statistics Descriptor
Hello Albrecht, The contribution certainly covers most use cases. I'm a little concerned that a 20 page appendix is an overkill for the description of statistics. I don't think the setting / resetting / deactivation is sufficiently different from normal properties/parameters to justify this amount of specification. If we go down the approach of document every case for the setting of statistics, do we need another appendix to show everycase for the setting of properties? another one to show call flows for the setting of signals. I think it is better to concentrate of the source of confusion and fix this rather than try to respecify the whole functionality. Unfortunately I couldn't make it to the last meeting to see the depth of confusion. Regards, Christian Albrecht.Schwarz@alcatel.de wrote:
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 <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:arturo.martin-de-nicolas@ericsson.com> ;
geoff.hunt@bt.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 protocol allows a 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 ;
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
together into the same action or
time during which statistics are not collected by
If this looks OK, I will alter
arturo.martin-de-nicolas@ericsson.com ; geoff.hunt@bt.com ; then I'd like to propose to this has the effect of the two commands transaction, the MGC can minimize the the MG. the IG and upload 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;
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:albrecht.schwarz@ties.itu.ch] linyangbo@huawei.com; 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 -----
participants (1)
-
Christian Groves