Re: [xrblock] comment on draft-ietf-xrblock-rtcp-xr-qoe-02.txt

Hi, Al:
Thank for your general comments, I take some time to look at the standards for calculation again. 
please see my replies inline.

Regards!
-Qin
----- Original Message ----- 
From: "Al Morton" <acmorton@att.com>
To: <xrblock@ietf.org>
Sent: Thursday, August 02, 2012 5:01 AM
Subject: [xrblock] comment on draft-ietf-xrblock-rtcp-xr-qoe-02.txt

> Regarding:
> http://tools.ietf.org/id/draft-ietf-xrblock-rtcp-xr-qoe-02.txt
> 
>>    Calculation Algorithm (CALg):3 bits
>>
>>          000 - ITU-T P.564 Compliant Algorithm [P.564] (Voice)
>>          001 - G.107 [G.107] (Voice)
>>          010 - ETSI TS 101 329-5 Annex E [ ETSI] (Voice)
>>          011 - ITU-T P.NAMS [P.NAMS] (Multimedia)
>>          100 - ITU-T P.NBAMS [P.NBAMS] (Multimedia)
>>          101~111 - Reserved for future extension.
>>
>>       G.107 and P.564 and ETSI TS101 329-5 specify three Calculation
>>       algorithms or MoS algorithms that are used to estimate speech
>>       quality or conversation quality.  P.NAMS and P.NBAMS specify two
>>       MoS algorithms that are used to estimate multimedia quality
>>       including video quality, audio quality and audio-video quality.
> 
> Specifying the standard for the calculation is a good start,
> but these standards all have options and input parameters
> that must also be specified in order to know what the MOS means.

> For example, we need to know what codec was used, because G.726
> carries an equipment Impairment factor that limits the upper
> bound on MOS, while G.711 does not.

[Qin]: I agree MoS value depends on the codec that is in use. That's why, in the current draft,
We use 7-bit payload Type in the metric block to signal what codec or payload format is
 in use for reporting interval. 
Please see the definition of Payload Type (PT) in the section 3.2.1.

> 
> Some of the input parameters will be assumed (e.g., at default values)
> while others will be measured, and the distinction between measured
> and assumed parameters should also be made.

[Qin]: 
The input parameters may come from Delay metric block, Discard metric block,
Burst Gap metrics block, JB metrics block, loss concealment metric block, concelament seconds
metrics block, these metrics blocks are defined in other XR Block drafts by XRBLOCK WG .

In QoE metric block, 4 or 5 pameters are defined, i.e.,
a.Segment Type
b.MoS Type
c.MoS algorithm
d. MoS value
In these parameters, a~c can be counted as default values while d is counted as measured value.
The other default values rely on specific computation model defined in each standard, e.g., 
P.564, G.104, P.NAMS.
Assume each standard only provide one algorithm or one model, we can use  the standards name and payload type(i.e.,codec) 
to identify each MoS algorithm used or each MoS model used.

> As I mentioned, metrics with many optional parameters are somewhat
> difficult to identify in a simple way, as we found with the IPPM
> Metrics Registry (which we withdrew when we found it was insufficient
> to describe the measurement results in an exact way).
> 
> Colin Perkins suggested the possibility a registry for the calculation alg.
> A registry could provide a single value index to a complicated set of
> input parameters and other assumptions, and this might work for you.

[Qin]: Yes,depends on the input parameters and option we got, we can calculate
the different MoS values however the computation model is same and will not be 
affected by the input parameters and options.
So maybe rather than registering MoS algorithm, we should register assessment model or computation model.
We can use computation model defined in the standard and payload type as single value index. 

> hope this helps,
> Al
> 
> 
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock
>