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

Christian Groves cngroves at bigpond.net.au
Thu Dec 15 19:27:41 EST 2005


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 at 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%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