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

[Qin Wu <[e-mail]>]

Hi, Alan:
Given the popularity of the Japan national standards (i.e.,TTC 201.01) in Japan, 
we can add TTC 201.01 based algorithm as one new calculation algorithm  in the
QoE Metric Block.
Currently we still allow support additional 5 new calculation algorithms using 3bit CAlg.

Regarding MoS Reference, are you suggesting we should differentiate low bit rate from high bit rate
or we should differeniate narrowband from wideband?
It looks to me narrowband and wideband only can be used with audio stream and don't apply to video?

Another question is I am not familiar with the terminology "MoS reference".
Would you like to point me a reference to explain what "MoS Reference" is?
Thanks!

Regards!
-Qin
 ----- Original Message ----- 
From: "Alan Clark" <[e-mail]>
To: "Qin Wu" <[e-mail]>; <[e-mail]>; "Al Morton" <[e-mail]>
Sent: Thursday, August 16, 2012 10:58 PM
Subject: Re: [xrblock] comment on draft-ietf-xrblock-rtcp-xr-qoe-02.txt


> 
> Some further work is definitely needed on this draft with regard to the MOS
> terminology. The various calculation methods for MOS either already do, or
> soon will, provide MOS values for narrowband, wideband, super wideband and
> fullband codecs; these MOS values occupy the same range and hence the QoE
> block needs to indicate what the MOS reference is.
> In addition there are national standards (e.g. Japan) that use a different
> MOS scaling.
> 
> Alan
> 
> 
> 
> On 8/15/12 10:33 PM, "Qin Wu" <[e-mail]> wrote:
> 
>> 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" <[e-mail]>
>> To: <[e-mail]>
>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/xrblock
>>> 
>> _______________________________________________
>> xrblock mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/xrblock
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock