Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discard-06.txt

Qin Wu <bill.wu@huawei.com> Mon, 03 September 2012 01:10 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 8876621F8498 for <xrblock@ietfa.amsl.com>; Sun, 2 Sep 2012 18:10:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.213
X-Spam-Level:
X-Spam-Status: No, score=-1.213 tagged_above=-999 required=5 tests=[AWL=2.748, 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 c8ffZKzTGGFT for <xrblock@ietfa.amsl.com>; Sun, 2 Sep 2012 18:10:53 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B33B521F844F for <xrblock@ietf.org>; Sun, 2 Sep 2012 18:10:51 -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.5-GA FastPath queued) with ESMTP id AJG95991; Mon, 03 Sep 2012 01:10:49 +0000 (GMT)
Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Sep 2012 02:10:05 +0100
Received: from SZXEML423-HUB.china.huawei.com (10.82.67.162) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Sep 2012 02:10:47 +0100
Received: from w53375 (10.138.41.149) by szxeml423-hub.china.huawei.com (10.82.67.162) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 3 Sep 2012 09:10:44 +0800
Message-ID: <186DB8B41E22446A83FD94F17A432385@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: Colin Perkins <csp@csperkins.org>
References: <EDC652A26FB23C4EB6384A4584434A0407F2ADF7@307622ANEX5.global.avaya.com> <CALw1_Q3o=G8TRRgYN1NUVa_R7dY_hcGjeP1z9jo+7Nzt35cZDw@mail.gmail.com> <12AC3B598E514219BE7EFA26F99C7FC3@china.huawei.com> <ACDBDDBB-E612-46CC-B730-D93AE692A1B6@csperkins.org>
Date: Mon, 03 Sep 2012 09:10:12 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0026_01CD89B3.EC570690"
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] WGLC for draft-ietf-xrblock-rtcp-xr-discard-06.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: Mon, 03 Sep 2012 01:10:54 -0000

The change looks good to me. Thanks!

Regards!
-Qin
  ----- Original Message ----- 
  From: Colin Perkins 
  To: Qin Wu 
  Cc: Kevin Gross ; Romascanu, Dan (Dan) ; xrblock@ietf.org 
  Sent: Saturday, September 01, 2012 12:17 AM
  Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discard-06.txt


  I agree that these changes should be incorporated before the draft goes to the IESG. I'd also suggest changing the following text in Section 3.2:


  OLD:
        Note that duplicating RTP packets is for robustness or error
        resilience but disrupts RTCP statitics.  In order to tackle this,
        the mechanism described in [RTPDUP] can be used which will not
        cause breakage of RTP streams or RTCP rules.


  NEW: 
        Some systems send duplicate RTP packets for robustness or error
        resilience. This is NOT RECOMMENDED since it breaks RTCP packet
        statistics. If duplication is desired for error resilience, the
        mechanism described in [RTPDUP] can be used, since this will not
        cause breakage of RTP streams or RTCP statistics.




  For clarity, I'd also suggest rewriting:


  OLD:
     Interval Metric flag (I): 2 bits


        This field is used to indicate whether the Discard Count Metric is
        an Interval or Cumulative metric, Sample metric [MONARCH],that is,
        whether the reported values applies to the most recent measurement
        interval duration between successive metrics reports (I=10) (the
        Interval Duration) or to the accumulation period characteristic of
        cumulative measurements (I=11) (the Cumulative Duration) or is a
        sampled instantaneous value (I=01) (Sampled Value).  In this
        document, Discard Count Metric is not measured at a particular
        time instant but over one or several reporting intervals.
        Therefore Discard Count Metric MUST not be chosen as Sampled
        Metric.


  NEW:
     Interval Metric flag (I): 2 bits


        This field indicates whether the reported metric is an interval,
        cumulative, or sampled metric [MONARCH]. The Discard Count Metric
        value can be reported as either an interval metric (I=10) or a
        cumulative metric (I=11). It does not make sense to report the
        Discard Count Metric as a sampled metric, so the value I=01 MUST
        NOT be used. The value I=00 is reserved, and MUST NOT be used.


  Otherwise, I have no objection to the draft progressing.


  Colin




  On 28 Aug 2012, at 02:23, Qin Wu wrote:
    Hi,Kevin:
    Your proposed improvement looks good to me.
    Thanks for your suggested text.

    Regards!
    -Qin
      ----- Original Message -----
      From: Kevin Gross
      To: Romascanu, Dan (Dan)
      Cc: xrblock@ietf.org
      Sent: Monday, August 27, 2012 10:06 PM
      Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-discard-06.txt


      I apologize that I was not more responsive to the recent thread (http://www.ietf.org/mail-archive/web/xrblock/current/msg00704.html) discussing revisions to this draft. I prepared the following wording improvements borrowing a bit from draft-ietf-xrblock-rtcp-xr-burst-gap-discard-05 to address my concerns about insufficient justification and context and trying to more comprehensively address Collin Perkins's concerns about leading implementers astray in duplication discussion.


Section 1.1., paragraph 3:
OLD:

    The metric belongs to the class of transport-related terminal metrics
    defined in [MONARCH].

NEW:

    This block may be used in conjunction with [BGDISCARD] which provides
    additional information on the pattern of discarded packets.  However
    the metric in [BGDISCARD] may be used independently of the metrics in
    this block.
 
    In case of Discard count metric block sent together with Burst gap
    discard metric block defined in [BGDISCARD] to the media sender or
    RTP based network management system, information carried in the
    discard count metric block and Burst gap discard metric block allows
    them calculate the some bust gap summary statistics, e.g., gap
    discard rate.
 
    The metric belongs to the class of transport-related terminal metrics
    defined in [MONARCH].


Section 1.4., paragraph 2:
OLD:

    In case of Discard count metric block sent together with Burst gap
    discard metric block defined in [BGDISCARD] to the media sender or
    RTP based network management system, information carried in the
    discard count metric block and Burst gap discard metric block allows
    them calculate the some bust gap summary statistics,e.g., gap discard
    rate.

NEW:

    Discards due to late or early arriving packets affects user
    experience.  The reporting of discards alerts senders and other
    receivers to the need to adjust their transmission or reception
    strategies.  The reports allow network managers to diagnose these
    user experience problems.


Section 1.4., paragraph 3:
OLD:

    In case of replication being kept "on", reporting duplicate packets
    discards allows the media sender or network management system
    determine what proportion of lost packets are being concealed by the
    process and calculate the actual loss rate which is helpful to know
    that there are some network issues that need to be investigated.

NEW:

    The ability to detect duplicate packets can be used by managers to
    detect network layer or sender behavior which may indicate network or
    device issues.  Based on the reports, these issues may be addressed
    prior to any impact on user experience.

      Kevin Gross

      +1-303-447-0517
      Media Network Consultant

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




      On Sun, Aug 26, 2012 at 12:41 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:

        This is a WGLC for draft-ietf-xrblock-rtcp-xr-discard-06.txt. Please
        send your questions, comments or concerns to the WG list before 9/9 COB.
        Messages indicating that you have read the document and are comfortable
        with it, including with the latest changes are also useful.

        The plain text version of the document is available at
        http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-discard-06.txt.


        The diff between versions 05 and 06 is accessible at
        https://www.ietf.org/rfcdiff?url1=draft-ietf-xrblock-rtcp-xr-discard-05&
        difftype=--html&submit=Go%21&url2=draft-ietf-xrblock-rtcp-xr-discard-06

        Thanks and Regards,

        Shiba and Dan
        _______________________________________________
        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






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