Re: [xrblock] Transport of I.D-xrblock-rtcp-xr-qoe style quality datain IPFIX

Qin Wu <bill.wu@huawei.com> Tue, 24 July 2012 03:23 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D458221F84D5 for <xrblock@ietfa.amsl.com>; Mon, 23 Jul 2012 20:23:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.308
X-Spam-Level:
X-Spam-Status: No, score=-5.308 tagged_above=-999 required=5 tests=[AWL=0.991, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBwWtH20bpRY for <xrblock@ietfa.amsl.com>; Mon, 23 Jul 2012 20:23:17 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9C721F8480 for <xrblock@ietf.org>; Mon, 23 Jul 2012 20:23:17 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AIH05640; Mon, 23 Jul 2012 23:23:16 -0400 (EDT)
Received: from DFWEML403-HUB.china.huawei.com (10.193.5.151) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Jul 2012 20:20:10 -0700
Received: from SZXEML404-HUB.china.huawei.com (10.82.67.59) by dfweml403-hub.china.huawei.com (10.193.5.151) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Jul 2012 20:20:08 -0700
Received: from w53375 (10.138.41.149) by szxeml404-hub.china.huawei.com (10.82.67.59) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 24 Jul 2012 11:20:05 +0800
Message-ID: <8D8E6A1D85AA4AD09E35ADC74F2DF8D4@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Michael Krüger <mkrueger@voipfuture.com>
References: <50040877.8040400@123.org><21EDE4323D7E465383A56DE5E1D6C853@china.huawei.com> <50068386.3040409@123.org> <1DB68734A3A342A8859EDEF1AE566491@china.huawei.com> <500D5C22.1080908@voipfuture.com>
Date: Tue, 24 Jul 2012 11:20:05 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.6109
X-Originating-IP: [10.138.41.149]
X-CFilter-Loop: Reflected
Cc: xrblock@ietf.org
Subject: Re: [xrblock] Transport of I.D-xrblock-rtcp-xr-qoe style quality datain IPFIX
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <xrblock.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xrblock>, <mailto:xrblock-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xrblock>
List-Post: <mailto:xrblock@ietf.org>
List-Help: <mailto:xrblock-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xrblock>, <mailto:xrblock-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jul 2012 03:23:17 -0000

Hi,Michael:
Thank for your clarification.
One thing I am not clear to your idea  is how to calculate MoS value or Rating value based on stream data from multiple sources?
Currently in QoE XR draft, we support MoS calculation per SSRC or MoS calculation per audio channel?
It seems you claim you can calculate MoS values based on audio data from multi-channels? 
Is that MoS value is the weighted mean of MoS value of each channel? If in that case, what the weight for each 
channel MoS calculation?
Maybe this is just implemenation specific issue, however I am interested to listen to that.

Regards!
-Qin

----- Original Message ----- 
From: "Michael Krüger" <mkrueger@voipfuture.com>
To: "Qin Wu" <bill.wu@huawei.com>
Cc: "Hendrik Scholz" <hs@123.org>; <xrblock@ietf.org>
Sent: Monday, July 23, 2012 10:13 PM
Subject: Re: [xrblock] Transport of I.D-xrblock-rtcp-xr-qoe style quality datain IPFIX


> Hi,
> 
> Am 23.07.12 04:43, schrieb Qin Wu:
>>>> Also it seems you give a range for each RTPMOSClass as follows:
>>>>
>>>> rtpMOSClass 1: MoS value < 3.10
>>>> rtpMOSClass 2:  3.10<=MoS value<3.60
>>>> rtpMOSClass 3:  3.60<=MoS value<4.03
>>>> rtpMOSClass 4:  4.03<=MoS value< 4.34
>>>> rtpMOSCalss 5: 4.34<= MoS value<=5
>>>>
>>>> I am wondering what the rationale is for such range allocation. which reference are you based on?
>>>
>>> This is based on ITU-T G.107 (table B.1) referring to the perceived user 
>>> experience.
>> 
>> [Qin]: Make sense.
>> Table B.1 is a good example to see translation between MoS value and Rating value.
>>  
>>>> Lastly why should the rtpMoSClass choose 'number of seconds' as unit?
>>>
>>> In order to calculate a MOS value multiple seconds worth of data have
>>> to be present to begin with (TM Forum claims 8-10 seconds).
>>> The data format is flexible in regards to as many seconds worth of
>>> data are transported in a single IPFIX record.
>>> Systems may use fixed time slices (e.g. one record for 30 seconds
>>> worth of stream data) or one record per (variable length) stream/call.
>>> An IPFIX mediator/collector or any data warehouse should be able
>>> to aggregate the data a) from multiple records belonging to a
>>> single streams and b) multiple records belonging to multiple streams.
>>>
>>> What unit were you thinking of?
>> 
>> [Qin]: I thought rtpMoSClass has no unit and 'Number of seconds the monitored stream'
>> should be regarded as a new information element in parallel with rtpMoSClass rather than
>> one attribute of rtpMoSClass. am I wrong?
> 
> This draft is suppose to support any measurement interval and that is
> the reason for having seconds as the unit. The measurement interval
> could be a few seconds of a flow or the complete call. To be able to
> collect these classes from different sources, which may use different
> measurement intervals, the seconds are needed. So the classes do not
> contain a count if segments of a flow had a MOS value within a specific
> class, but rather how many seconds of the flow have been in that class.
> That way it is possible to combine measurements from different sources,
> which is the idea behind the draft.
> The application of this can then be a report to show how many minutes of
> transported VoIP traffic for a day/week/month have been in any of the 5
> classes.
> 
> Regards,
> Michael
> 
>>>
>>> Thanks for your feedback,
>>>  Hendrik
>>>
>>> -- 
>>> Hendrik Scholz <hs@123.org>
>>>
>>>
>>> _______________________________________________
>>> xrblock mailing list
>>> xrblock@ietf.org
>>> https://www.ietf.org/mailman/listinfo/xrblock
>> _______________________________________________
>> xrblock mailing list
>> xrblock@ietf.org
>> https://www.ietf.org/mailman/listinfo/xrblock
>> 
>