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