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

Qin Wu <bill.wu@huawei.com> Tue, 02 April 2013 03:18 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 554FB21E814C for <xrblock@ietfa.amsl.com>; Mon, 1 Apr 2013 20:18:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.473
X-Spam-Level:
X-Spam-Status: No, score=-3.473 tagged_above=-999 required=5 tests=[AWL=1.041, BAYES_00=-2.599, 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 iPowfErQF8AO for <xrblock@ietfa.amsl.com>; Mon, 1 Apr 2013 20:18:00 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB5821E8140 for <xrblock@ietf.org>; Mon, 1 Apr 2013 20:17:57 -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 APZ19696; Tue, 02 Apr 2013 03:17:56 +0000 (GMT)
Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Apr 2013 04:17:31 +0100
Received: from SZXEML457-HUB.china.huawei.com (10.82.67.200) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Apr 2013 04:17:24 +0100
Received: from w53375 (10.138.41.149) by szxeml457-hub.china.huawei.com (10.82.67.200) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Apr 2013 11:17:18 +0800
Message-ID: <B54B495219F944CFA338CE578D25A27C@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Kevin Gross <kevin.gross@avanw.com>
References: <CALw1_Q2z3nDwpRJSNomRqFVQhWAN7-7YozUL6GPEppKzL=6W1w@mail.gmail.com><CD5A7C1E.4EAD1%alan.d.clark@telchemy.com><CALw1_Q0HX9EXir5F4b4=q7j7WBdGnr-5WTjz+A3qzQUU9xnfaA@mail.gmail.com><B8F9A780D330094D99AF023C5877DABA43A2BACF@nkgeml501-mbs.china.huawei.com><CALw1_Q3gQ-SibWWD0JOJjMjehnLr8CYNwE3VWszLJxcA2B0RhA@mail.gmail.com><B8F9A780D330094D99AF023C5877DABA43A30DCD@nkgeml501-mbs.china.huawei.com><CALw1_Q0ACRGDA3=s7az-B-Xm3f64FAb_ZO6pbk+zTm9o80aD4A@mail.gmail.com><FAE04602D1684209BFFF92D1283A4A9C@china.huawei.com> <CALw1_Q3YzCtWruDvS5PeKmu1z=BKf3bMCkRHLHjwLceeEb-V6Q@mail.gmail.com>
Date: Tue, 2 Apr 2013 11:17:17 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00F1_01CE2F93.A2797590"
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 03:18:01 -0000

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.