Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt

Qin Wu <bill.wu@huawei.com> Tue, 02 April 2013 08:29 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 AEBCA21F9846 for <xrblock@ietfa.amsl.com>; Tue, 2 Apr 2013 01:29:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.988
X-Spam-Level:
X-Spam-Status: No, score=-2.988 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, FAKE_REPLY_C=2.012, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, J_CHICKENPOX_64=0.6, J_CHICKENPOX_82=0.6, 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 OGadz7ivyyP2 for <xrblock@ietfa.amsl.com>; Tue, 2 Apr 2013 01:29:30 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A19C321F9864 for <xrblock@ietf.org>; Tue, 2 Apr 2013 01:29:25 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id APZ42210; Tue, 02 Apr 2013 08:29:24 +0000 (GMT)
Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Apr 2013 09:29:13 +0100
Received: from SZXEML462-HUB.china.huawei.com (10.82.67.205) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Apr 2013 16:29:20 +0800
Received: from w53375 (10.138.41.149) by szxeml462-hub.china.huawei.com (10.82.67.205) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Apr 2013 16:29:14 +0800
Message-ID: <2B351F3CA2AF40BA816EB2B6A8F7246D@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Kevin Gross <kevin.gross@avanw.com>
Date: Tue, 2 Apr 2013 16:29:13 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_014E_01CE2FBF.3659B1F0"
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 <xrblock@ietf.org>
Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt
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, 02 Apr 2013 08:29:31 -0000

Hi,Kevin:
Here is the update to address your concern.
http://www.ietf.org/internet-drafts/draft-ietf-xrblock-rtcp-xr-jb-10.txt
The diff is
http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-jb-10

Regards!
-Qin


  ----- Original Message ----- 
  From: Qin Wu 
  To: Kevin Gross 
  Cc: Alan Clark ; xrblock ; Romascanu, Dan (Dan) ; Shida Schubert 
  Sent: Tuesday, April 02, 2013 11:17 AM
  Subject: Re: Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt


  Hi, Kevin:
  Thank for your response, see my reply inline below.

  Regards!
  -Qin
    ----- Original Message ----- 
    From: Kevin Gross 
    To: Qin Wu 
    Cc: Alan Clark ; xrblock ; Romascanu, Dan (Dan) ; Shida Schubert 
    Sent: Tuesday, April 02, 2013 5:12 AM
    Subject: Re: Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt


    Hi Qin,


    Responses below.


    Kevin



    On Wed, Mar 20, 2013 at 6:45 AM, Qin Wu <bill.wu@huawei.com> wrote:

      Hi,Kevin:
      Thank for your quick checking.
      Please see my reply inline.

      Regards!
      -Qin
        ----- Original Message ----- 
        From: Kevin Gross 
        To: Qin Wu 
        Cc: Alan Clark ; xrblock@ietf.org ; Romascanu, Dan (Dan) ; Shida Schubert 
        Sent: Sunday, March 17, 2013 6:10 AM
        Subject: Re: Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-08.txt


        I said my contributions were rough and it doesn't look like they were improved much in the new revision.


        Section 3 


        "The delay applied to
   packets that arrive at their expected time is known as the Nominal
   Delay and this is equivalent to the late edge."Nominal delay is not equivalent to late edge. [Qin]: Please refer to example provide by Alan in Jan 16,2013 when clarifing to Roni on what nominal delay means.http://www.ietf.org/mail-archive/web/xrblock/current/msg01090.htmlOne sentence in Alan's example I highlighted here is:"So the nominal delay is the time difference/ buffer size difference between the on-time insertion point and the point at which packets are read out and decoded."So the nominal delay is equivalent to the time difference between the expected arrival time and the time when a late arriving packet is consumed.or we can say nominal delay is equivalent to late edge, what am I missing?

    If we are not including decoder delay in this discussion, I think you're right about this. I'm now too close to this to be able to tell whether it is explained clearly. Hopefully others will review.

  [Qin]: Okay, I agree with you that the decoder delay should not be taken into account. So the sentence I am referrring will be rephrased like this:
  "
  So the nominal delay is the time difference/ buffer size difference between the on-time packets insertion point and the point at which packets are read out.
  " 

Section 3.2"The fixed jitter buffers have a fixed size and the packets leaving
   the jitter buffer have a constant delay."There is just one jitter buffer and we need a bit more elaboration on how a fixed jitter buffer is used, its limitations and how maximum delay and nominal delay are reported for it. [Qin]: I believe these have been explained in the Definition of Fields in Jitter Buffer Metrics Block of section 4.2.

    I don't see it. Section 4.2 is the longest section. Fixed jitter buffer term is used there but never defined or elaborated on. In any case, this does not address my concern about singular vs. plural buffers and subject-verb disagreement here.

  [Qin]: You are right. It should be singular. To address your concern, I propose the following change to section 3.2:
  OLD TEXT
  "
Section 3.2"The fixed jitter buffers have a fixed size and the packets leaving
   the jitter buffer have a constant delay.""
  NEW TEXT:
  "
Section 3.2A fixed jitter buffer lacks provision to track network condition and  has a fixed size and packets leaving the jitter buffer.have a constant delay. For fixed jitter buffer implementation, the maximum delay is set to a constant value corresponding to the fixed size of the jitter buffer. The nominal delay is set to a constant value corresponding to the packets that arrive at their expected arrival time.

  "
Section 3.3"An adaptive jitter buffer have variable size and variable delay."Fix grammar. Change "and" to "or" or "and/or". [Qin]: Agree, thanks.

    Just to be clear, those are two separate complaints. There are several instances of subject-verb disagreements. We can say those are just editorial issues but I think they need to be addressed here because it it is not always clear from context whether singular or plural is intended.

  [Qin]:My fault. I think it should be singular and will fix this.