Re: [xrblock] WGLC review ofdraft-ietf-xrblock-rtcp-xr-burst-gap-loss-02 anddraft-ietf-xrblock-rtcp-xr-burst-gap-discard-04

Qin Wu <bill.wu@huawei.com> Mon, 23 July 2012 03:59 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 C3A5721F86B3 for <xrblock@ietfa.amsl.com>; Sun, 22 Jul 2012 20:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.13
X-Spam-Level:
X-Spam-Status: No, score=-4.13 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, 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 6aj4Atv+5fnH for <xrblock@ietfa.amsl.com>; Sun, 22 Jul 2012 20:59:24 -0700 (PDT)
Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8114A21F86B0 for <xrblock@ietf.org>; Sun, 22 Jul 2012 20:59:24 -0700 (PDT)
Received: from 172.18.9.243 (EHLO dfweml202-edg.china.huawei.com) ([172.18.9.243]) by dfwrg02-dlp.huawei.com (MOS 4.2.3-GA FastPath) with ESMTP id AHZ27313; Sun, 22 Jul 2012 23:59:24 -0400 (EDT)
Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by dfweml202-edg.china.huawei.com (172.18.9.108) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Jul 2012 20:57:03 -0700
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by dfweml407-hub.china.huawei.com (10.193.5.132) with Microsoft SMTP Server (TLS) id 14.1.323.3; Sun, 22 Jul 2012 20:57:02 -0700
Received: from w53375 (10.138.41.149) by szxeml411-hub.china.huawei.com (10.82.67.138) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 23 Jul 2012 11:56:55 +0800
Message-ID: <BDEB1C585843466F8F7198B1AB0DC359@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Roni Even <ron.even.tlv@gmail.com>, 'xrblock' <xrblock@ietf.org>
References: <011601cd6428$35c14360$a143ca20$@gmail.com>
Date: Mon, 23 Jul 2012 11:56:54 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_054A_01CD68CA.41126720"
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
Subject: Re: [xrblock] WGLC review ofdraft-ietf-xrblock-rtcp-xr-burst-gap-loss-02 anddraft-ietf-xrblock-rtcp-xr-burst-gap-discard-04
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: Mon, 23 Jul 2012 03:59:25 -0000

Hi,Roni:
Thank for your valuable review. please see my replies inline.

Regards!
-Qin
  ----- Original Message ----- 
  From: Roni Even 
  To: 'xrblock' 
  Sent: Tuesday, July 17, 2012 10:26 PM
  Subject: [xrblock] WGLC review ofdraft-ietf-xrblock-rtcp-xr-burst-gap-loss-02 anddraft-ietf-xrblock-rtcp-xr-burst-gap-discard-04


  Hi,

  I reviewed both drafts and in general they look OK.

  I have a couple of questions/comments for both drafts

   

  1.       In section 2.1 for Received, Lost and Discarded why not use the similar text from draft-ietf-xrblock-rtcp-xr-discard?



[Qin]:Good suggestions. For consistency, we should use the same term in both burst gap drafts and discard drafts.

Also I am aware that in the section 2.1 of discard draft, the discard count metric has no difference from 'number of packets discarded'metric.

Therefore I propose the following change.

OLD TEXT:

"

   Received, Lost and Discarded

      A packet shall be regarded as lost if it fails to arrive within an
      implementation-specific time window.  A packet that arrives within
      this time window but is too early or late to be played out or
      thrown away before playout due to packet duplication or redundancy
      shall be regarded as discarded.  A packet shall be classified as
      one of received (or OK), discarded or lost.  The Discard Count
      Metric counts only discarded packets.  The metric "cumulative
      number of packets lost" defined in [RFC3550] reports a count of
      packets lost from the media stream (single SSRC within single RTP
      session).  Similarly the metric "number of packets discarded"
      reports a count of packets discarded from the media stream (single
      SSRC within single RTP session) arriving at the receiver.  Another
      metric defined in [RFC5725] is available to report on packets
      which are not recovered by any repair techniques which may be in
      use.

"

NEW TEXT:

"

   Received, Lost and Discarded

 

      A packet shall be regarded as lost if it fails to arrive within an

      implementation-specific time window.  A packet that arrives within

      this time window but is too early or late to be played out or

      thrown away before playout due to packet duplication or redundancy

      shall be regarded as discarded.  A packet shall be classified as

      one of received (or OK), discarded or lost. The metric "cumulative

      number of packets lost" defined in [RFC3550] reports a count of

      packets lost from the media stream (single SSRC within single RTP

      session).  Similarly the metric "number of packets discarded"

      defined in [DISCARD]reports a count of packets discarded from the media stream (single

      SSRC within single RTP session) arriving at the receiver.  Another

      metric defined in [RFC5725] is available to report on packets

      which are not recovered by any repair techniques which may be in

      use. 

"



  2.       Section 4 talks about considerations for VOIP and recommends a value for call quality degradation. Can we have something similar for video, at least in the second paragraph which I think is not voice specific. 

[Qin]: We already have. pleas see the 2nd term in the section 2.1 as follows:

"

   Bursts and Gaps

      The terms Burst and Gap are used in a manner consistent with that
      of RTCP XR [RFC3611].  RTCP XR views a RTP stream as being divided
      into bursts, which are periods during which the discard rate is
      high enough to cause noticeable quality degradation (generally
      over 5 percent discard rate), and gaps, which are periods during
      which discarded packets are infrequent and hence quality is
      generally acceptable.

"



  3.       In section 4 the degradation in quality mentioned is when there is no redundancy information like FEC  so maybe mentioned that this value is without any stream repair means.



[Qin]: Good suggestion and will add.

  4.       A nit in section 4 first paragraph "Where the metric is used" maybe say "when the."



[Qin]:Confirmed, yes. Thank for your proposed change.

   

   

  Roni Even



------------------------------------------------------------------------------


  _______________________________________________
  xrblock mailing list
  xrblock@ietf.org
  https://www.ietf.org/mailman/listinfo/xrblock