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

Qin Wu <bill.wu@huawei.com> Tue, 18 December 2012 01:38 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 AA99221F8436 for <xrblock@ietfa.amsl.com>; Mon, 17 Dec 2012 17:38:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.241
X-Spam-Level:
X-Spam-Status: No, score=-4.241 tagged_above=-999 required=5 tests=[AWL=-0.280, 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38gKnEnGbmkw for <xrblock@ietfa.amsl.com>; Mon, 17 Dec 2012 17:38:43 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F2A8921F847F for <xrblock@ietf.org>; Mon, 17 Dec 2012 17:38:41 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANX83579; Tue, 18 Dec 2012 01:38:40 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Dec 2012 01:38:33 +0000
Received: from SZXEML411-HUB.china.huawei.com (10.82.67.138) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.3; Tue, 18 Dec 2012 01:38:38 +0000
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; Tue, 18 Dec 2012 09:38:35 +0800
Message-ID: <686F7A581585402D82BDCA8F213EB5E7@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Kevin Gross <kevin.gross@avanw.com>
References: <FAB2D6A6BD794F67B5EF665FB7966291@china.huawei.com><9904FB1B0159DA42B0B887B7FA8119CA021171@AZ-FFEXMB04.global.avaya.com><-5577438416726931362@unknownmsgid><9904FB1B0159DA42B0B887B7FA8119CA02129A@AZ-FFEXMB04.global.avaya.com><56FF1AB29F4046F0BDCDF6F7B21FC0EC@china.huawei.com> <CALw1_Q1UfwNR+7jNx=r+P3rMR35NRdby_S+Xh1GADivvx3_r6w@mail.gmail.com>
Date: Tue, 18 Dec 2012 09:38:34 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_028E_01CDDD03.72F176C0"
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] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.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, 18 Dec 2012 01:38:48 -0000

Hi, Kevin:
Thank for your feedback and valuable review. Please see my reply inline.

Regards!
-Qin
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Qin Wu 
  Cc: Romascanu, Dan (Dan) ; Varun Singh ; xrblock@ietf.org 
  Sent: Tuesday, December 18, 2012 5:41 AM
  Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt


  Sorry for the delay in getting these comments published. I had originally reviewed version 01. Some of my minor comments were resolved in this new version and so are not included here.




  Section 1.2


  RFC 3611 is still in force - 
  s/[RFC3611] defined/[RFC3611] defines


[Qin]:Okay.

  Section 1.3


  Missing conjunction - 
  s/guidelines in [RFC6390][RFC6792]/guidelines in [RFC6390] and [RFC6792]



[Qin]:Okay.

  Section 3.2


  Jitter Buffer Configuration
  I think the two reporting options are potentially over simplification of how these systems can work. An adaptive receiver has to adapt to maximum latency and to delay variation. The former is accomplish by adjusting the playout delay, the latter by reallocating buffer space. I suggest we might want to report these behaviors separately, for example:
    00 - fixed jitter buffer and delay
    10 - adaptive playout delay
    01 - adaptive buffer size
    11 - adaptive delay and size

[Qin]:Sounds good to me.


  Block length
  Is requirement to discard reports with unexpected length common practice with these reports? The alternative is to allow reports to be revised to increased size with appended data. Original implementations then ignore anything beyond the original size. It's a little more flexible but maybe we don't want to go there. I've checked RFC 3611 and don't see any guidance on this. It would be nice to specify consistent behavior around this for all reports.

[Qin]:Yes. I have fixed this with adding the following sentence to say:
"
The block MUST be discarded if the block length is

      set to a different value.

"


  Jitter buffer nominal delay
  Needs to specify reference points for reported delay: From receipt to playout? From RTP timestamp to playout?

[Qin]:One reference point is the packet that arrives exact on time.
  If one of the reference points is a playout time, and depending on expected use cases, higher resolution may be justified here.
[Qin]:What's your suggested change? How about adding the following sentence to say:
"
It is calculated based on the difference between the receipt time and playout time for the packet that 
arrives exactly on time.
"
  Jitter buffer maximum delay
  Needs to specify reference points for reported delay: From receipt to playout? From RTP timestamp to playout?

[Qin]: How about adding the following sentence to say:
"
Jitter buffer maximum delay is calculated based on the difference between the receipt time and playout time
for the earliest arriving packet"


  Another clarification - 
  s/correspond to the nominal size./correspond to the size of the jitter buffer.

[Qin]: Make sense to me.


  Jitter buffer high water mark
  Explain whether this applies to fixed jitter buffer or only to adaptive.
[Qin]: I think "Jitter buffer high water mark" applies to adaptive jitter buffer implementation.
its value MUST be set to jitter buffer maximum delay for fixed jitter buffer implementations.
How about adding one sentence to say:
"
This parameter MUST be provided for
 adaptive jitter buffer implementations and its value MUST be
 set to JB maximum for fixed jitter buffer implementations.

"




  Jitter buffer low water mark
  Explain whether this applies to fixed jitter buffer or only to adaptive.

[Qin]:Same proposed change above.



  Kevin Gross
  +1-303-447-0517
  Media Network Consultant

  AVA Networks - www.AVAnw.com, www.X192.org




  On Mon, Nov 26, 2012 at 5:51 PM, Qin Wu <bill.wu@huawei.com> wrote:

    Sorry, I forgot what Kevin said in the last presentation.
    I think Dan's proposal looks good.:-)

    Regards!
    -Qin

    ----- Original Message -----
    From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
    To: "Varun Singh" <vsingh.ietf@gmail.com>
    Cc: "Qin Wu" <bill.wu@huawei.com>om>; <xrblock@ietf.org>
    Sent: Monday, November 26, 2012 9:25 PM
    Subject: RE: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-02.txt


    Indeed, this was Kevin Gross.

    The question is whether Kevin's comments could be made during the WGLC, or they are severe enough to make us wait before issuing a LC. I hope that Kevin can answer this.

    Thanks and Regards,

    Dan



    > -----Original Message-----
    > From: Varun Singh [mailto:vsingh.ietf@gmail.com]
    > Sent: Monday, November 26, 2012 3:18 PM
    > To: Romascanu, Dan (Dan)
    > Cc: Qin Wu; xrblock@ietf.org
    > Subject: Re: [xrblock] Fw: I-D Action: draft-ietf-xrblock-rtcp-xr-jb-
    > 02.txt
    >
    > Hi,
    >
    > AFAIR, someone (maybe Kevin Gross) remarked that he had some comments on
    > the draft.
    >
    > Regards,
    > Varun
    >
    > ----
    > http://www.netlab.tkk.fi/~varun
    >
    > On 26.11.2012, at 18.10, "Romascanu, Dan (Dan)" <dromasca@avaya.com>
    > wrote:
    >
    > > Thanks, Qin.
    > >
    > > Unless somebody has good reasons to object we shall issue the last
    > call in the coming days.
    > >
    > > Regards,
    > >
    > > Dan
    > >
    > >
    > >
    > >> -----Original Message-----
    > >> From: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] On
    > >> Behalf Of Qin Wu
    > >> Sent: Monday, November 26, 2012 10:57 AM
    > >> To: xrblock@ietf.org
    > >> Subject: [xrblock] Fw: I-D Action:
    > >> draft-ietf-xrblock-rtcp-xr-jb-02.txt
    > >>
    > >> On 26 November , 2012 4:54 PM, Internet-Drafts@ietf.org wrote:
    > >>>
    > >>> A New Internet-Draft is available from the on-line Internet-Drafts
    > >> directories.
    > >>> This draft is a work item of the Metric Blocks for use with RTCP's
    > >> Extended Report Framework Working Group of the IETF.
    > >>>
    > >>> Title           : RTP Control Protocol (RTCP) Extended Report (XR)
    > >> Block for Jitter Buffer Metric Reporting
    > >>> Author(s)       : Alan Clark
    > >>>                         Varun Singh
    > >>>                         Qin Wu
    > >>> Filename        : draft-ietf-xrblock-rtcp-xr-jb-02.txt
    > >>> Pages           : 14
    > >>> Date            : 2012-11-26
    > >>>
    > >>> Abstract:
    > >>>  This document defines an RTP Control Protocol (RTCP) Extended
    > >>> Report
    > >>>  (XR) Block that allows the reporting of Jitter Buffer metrics for a
    > >>> range of RTP applications.
    > >>>
    > >>>
    > >>> The IETF datatracker status page for this draft is:
    > >>> https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-jb
    > >>
    > >>
    > >> [Qin]: I believe this version address resolve the comments discussed
    > >> in the last Atalanta IETF meeting and now is ready for WGLC.
    > >> _______________________________________________
    > >> 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
    _______________________________________________
    xrblock mailing list
    xrblock@ietf.org
    https://www.ietf.org/mailman/listinfo/xrblock