[xrblock] 转发: ops-dir review of draft-ietf-xrblock-rtcp-xr-loss-conceal-10

Qin Wu <bill.wu@huawei.com> Sat, 29 March 2014 03:31 UTC

Return-Path: <bill.wu@huawei.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989491A0434 for <xrblock@ietfa.amsl.com>; Fri, 28 Mar 2014 20:31:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.078
X-Spam-Level: **
X-Spam-Status: No, score=2.078 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, CN_BODY_35=0.339, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VUN5eQwaYpAq for <xrblock@ietfa.amsl.com>; Fri, 28 Mar 2014 20:31:10 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5E9451A0436 for <xrblock@ietf.org>; Fri, 28 Mar 2014 20:31:10 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BCN53006; Sat, 29 Mar 2014 03:31:07 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 29 Mar 2014 03:30:25 +0000
Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 29 Mar 2014 03:31:06 +0000
Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.85]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.03.0158.001; Sat, 29 Mar 2014 11:31:02 +0800
From: Qin Wu <bill.wu@huawei.com>
To: "xrblock@ietf.org" <xrblock@ietf.org>
Thread-Topic: ops-dir review of draft-ietf-xrblock-rtcp-xr-loss-conceal-10
Thread-Index: Ac9EP1GAEfXLX+wdRQexAZEQCXhwhgCxe69QABY6fYAAG1/mkAAVgbcgAB3axBAAAREnAAAZXhOAAH8UebA=
Date: Sat, 29 Mar 2014 03:31:01 +0000
Message-ID: <B8F9A780D330094D99AF023C5877DABA8450D5FB@nkgeml501-mbs.china.huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.138.41.115]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/o8gcphHgVgyB1OKSMODQiLIm5rw
Subject: [xrblock] 转发: ops-dir review of draft-ietf-xrblock-rtcp-xr-loss-conceal-10
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.15
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: Sat, 29 Mar 2014 03:31:12 -0000

Hi,Colin:
I agree with your comment. Thanks for your proposed change. 

Regards!
-Qin
-----邮件原件-----
发件人: Colin Perkins [mailto:csp@csperkins.org] 
发送时间: 2014年3月27日 6:51
收件人: Qin Wu
主题: Re: ops-dir review of draft-ietf-xrblock-rtcp-xr-loss-conceal-10

Qin,

[inline]

On 26 Mar 2014, at 02:46, Qin Wu <bill.wu@huawei.com> wrote:
> Hi, Colin:
> Let me know what you think of the following options for addressing ops-dir review comments?
> 
> Regards!
> -Qin
> -----邮件原件-----
> 发件人: Qin Wu 
> 发送时间: 2014年3月26日 10:45
> 收件人: 'xrblock@ietf.org'
> 抄送: 'csp@csperkins.org'
> 主题: Re: ops-dir review of draft-ietf-xrblock-rtcp-xr-loss-conceal-10
> 
> Hi,
> In the OPS-DIR review, our reviewer asked to provide the hex value of the default threshold setting and one rounding issue was brought up.
> The related paragraph in the draft is:
> "
>>>   SCS Threshold: 8 bits
>>> 
>>>      The SCS Threshold is defined as the percentage of packets
>>>      corresponding to lost or discarded frames that must occur within a
>>>      one second period in order for the second to be classified as a
>>>      Severely Concealed Second.  This is expressed in numeric format
>>>      0:8 and hence can represent a range of 0.1 to 25.5 percent loss or
>>>      discard.
>>> 
>>>      A default threshold of 5% effective frame loss (50ms effective
>>>      frame loss ) per second is suggested.
> "
> The SCS threshold is represented in percentage. When we use numeric format 0:8 to represent the default value of SCS threshold, we only can represent 0.05078125 rather than 0.05 or 5% (which is set as the default value of threshold in the draft).
> 
> If we change the default threshold value into 0.05078125 and the hex value of 0.05078125 is 0x0D, This rounding issue can be resolved. 

This makes sense to me. I would just say “A default threshold of 5% effective frame loss (50ms effective frame loss) per second is suggested. This corresponds to an SCS Threshold in hexadecimal of 0x0D.”

I don’t think the rounding is important.

Colin



> Alternatively, we can change unit of SCS threshold back into millisecond, we can precisely represent 5% frame loss per second or the default threshold value 0.05. The range of 0.1 to 25.5 percentage can be represented into the range from 1ms effective frame loss to 255ms effective frame loss.
> 
> Regards!
> -Qin



-- 
Colin Perkins
http://csperkins.org/