Subject: Re: [xrblock] 答复: General comments on xrblock metrics drafts

From: [email-masked]
Date: Tue, 1 Nov 2011 16:21:00 +0800 (CST)

Are you saying the sample semantics has already been incorporate into Interval/Cumulative indication?

Cheers!

Jing

------------------ 原始邮件 ------------------

发件人：Qin Wu

时　间：2011/11/01 15:19:54 星期二

收件人：Alan Clark

, [email-masked]

抄送人：xrblock

主　题：答复: [xrblock] General comments on xrblock metrics drafts

Hi, Alan:

So the Interval metric you understand is for per RTP packet monitoring or observation while the sampled metric is not.
In other words,
a. The Interval metric is obtained by keeping trace of each RTP packet during a specified Interval and treat all the sequence number valid.
b.The sampled metric is obtained by sampling a sub set of RTP packets during a specified Interval.
Is that what you say?

However according to PDV drafts and other similar xrblock metrics drafts, per-packet statistics doesn't apply to these metrics(See security consideration section).

That seems to implicate that both Interval metrics and cumulative metric are not used for per-packet accounting but for sampling use.

Regards!

-Qin

发件人: [email-masked] [[email-masked]] 代表 Alan Clark [[email-masked]]
发送时间: 2011年10月31日 20:08
到: [email-masked]
Cc: xrblock
主题: Re: [xrblock] General comments on xrblock metrics drafts

Hi Jing

An interval metric should be measured throughout an interval however a sampled metric is an instantaneous value.

Using Jitter/PDV as an example:

- Interval PDV should be calculated by measuring the delay variation of each packet and averaging these over the interval. This requires the implementation to sum the individual measurements and divide by the number of measurements.

- PPDV (RFC3550) is calculated by keeping a running average of the individual delay variation measurements using a scaling factor of 16 and then reporting the value of this running average at the end of the interval. With a scaling factor of 16 the PPDV metric is most strongly affected by the delay variation of the most recent 10-20 packets and hence is not representative of the whole interval.

Interval averages can be quite misleading if the measurements are strongly time varying, which PDV typically is.

Best Regards

Alan

On 10/31/11 5:23 AM, "[email-masked]" <[email-masked]> wrote:

Hi, Alan:

Question for clarification.

Isn't the sampled metric same as the Interval metric? Is the sampled metric only applied to per-packet reporting ? what's the difference between sampled metric and non-sampled metric?

what's the difference between sampled metric and Interval metric? Would you like to clarify more?

Cheers!

Jing

------------------ 原始邮件 ------------------

发件人：Alan Clark
时　间：2011/10/31 06:51:03 星期一
收件人：[email-masked]
抄送人：
主　题：[xrblock] General comments on xrblock metrics drafts

1. Cumulative, Interval and Sample metrics
The drafts current have one bit assigned for Cumulative/Interval indication... Some metrics are however sampled and don’t have validity for an interval or a call/session; an example of this is PPDV, which is a sampled value of a running average and only has validity for the last 200-300ms before the value is sampled.
Proposal - increase this to two bits to allow for the indication of a Sampled value.

---

From: Alan Clark <[email-masked]>
Date: Tue, 1 Nov 2011 17:25:01 -0400

Jing

An Interval metric is calculated over the interval - so packet loss for an
interval would be the packets lost during the interval divided by the number
of packets expected.

If the packet loss rate was continuously calculated as a running average
(updated per packet) and the value of this packet loss rate metric was
sampled at the end of the interval, it would be a sampled value of the
metric and not the interval value.

Hence there is a difference between an interval metric and a sampled metric,
which IMHO means that we should have a way to state that a metric is
Cumulative, Interval or Sampled.

Best Regards

Alan

On 11/1/11 4:21 AM, "[email-masked]" <[email-masked]> wrote:

> 收件人：Alan Clark   , [email-masked]
> 抄送人：xrblock   
> So the Interval metric you understand is for per RTP packet monitoring or
> observation while the sampled metric is not.
> In other words,
> a. The Interval metric is obtained by keeping trace of each RTP packet during
> a specified Interval and treat all the sequence number valid.
> However according to PDV drafts and other similar xrblock metrics drafts,
> per-packet statistics doesn't apply to these metrics(See security
> consideration section).
>   
> 
> That seems to implicate that both Interval metrics and cumulative metric are
> not used for per-packet accounting but for sampling use.
>   
> 
>  
>   
> 
> Regards!
>   
> 
> -Qin
>   
>   
> 
>   
> - Interval PDV should be calculated by measuring the delay variation of each
> packet and averaging these over the interval. This requires the implementation
> to sum the individual measurements and divide by the number of measurements.
> 
> - PPDV (RFC3550) is calculated by keeping a running average of the individual
> delay variation measurements using a scaling factor of 16 and then reporting
> the value of this running average at the end of the interval. With a scaling
> factor of 16 the PPDV metric is most strongly affected by the delay variation
> of the most recent 10-20 packets and hence is not representative of the whole
> interval.
> 
> On 10/31/11 5:23 AM, "[email-masked]
> <https://imail.huawei.com/OWA/UrlBlockedError.aspx> " <[email-masked]
> <https://imail.huawei.com/OWA/UrlBlockedError.aspx> > wrote:
> 
>   
>>  
>> Hi, Alan: 
>> 
>> Isn't the sampled metric same as the Interval metric? Is the sampled metric
>> only applied to per-packet reporting ? what's the difference between sampled
>> metric and non-sampled metric?
>> 
>> 收件人：[email-masked] <https://imail.huawei.com/OWA/UrlBlockedError.aspx>
>> 抄送人： 
>> The drafts current have one bit assigned for Cumulative/Interval
>> indication... Some metrics are however sampled and don’t have validity for an
>> interval or a call/session; an example of this is PPDV, which is a sampled
>> value of a running average and only has validity for the last 200-300ms
>> before the value is sampled.