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

Colin Perkins <csp@csperkins.org> Fri, 31 August 2012 16:17 UTC

Return-Path: <csp@csperkins.org>
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 0D36A21F84C4 for <xrblock@ietfa.amsl.com>; Fri, 31 Aug 2012 09:17:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.107
X-Spam-Level:
X-Spam-Status: No, score=-103.107 tagged_above=-999 required=5 tests=[AWL=-0.393, BAYES_00=-2.599, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
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 KHGH1BOjNy-T for <xrblock@ietfa.amsl.com>; Fri, 31 Aug 2012 09:17:51 -0700 (PDT)
Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 4AD4B21F849C for <xrblock@ietf.org>; Fri, 31 Aug 2012 09:17:51 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1T7Tuo-0000AM-jO; Fri, 31 Aug 2012 16:17:50 +0000
Mime-Version: 1.0 (Apple Message framework v1278)
Content-Type: multipart/alternative; boundary="Apple-Mail=_14AFBC0B-FD4E-44FE-8DF2-7052D6F1C55D"
From: Colin Perkins <csp@csperkins.org>
X-Priority: 3
In-Reply-To: <12AC3B598E514219BE7EFA26F99C7FC3@china.huawei.com>
Date: Fri, 31 Aug 2012 17:17:46 +0100
Message-Id: <ACDBDDBB-E612-46CC-B730-D93AE692A1B6@csperkins.org>
References: <EDC652A26FB23C4EB6384A4584434A0407F2ADF7@307622ANEX5.global.avaya.com> <CALw1_Q3o=G8TRRgYN1NUVa_R7dY_hcGjeP1z9jo+7Nzt35cZDw@mail.gmail.com> <12AC3B598E514219BE7EFA26F99C7FC3@china.huawei.com>
To: Qin Wu <bill.wu@huawei.com>
X-Mailer: Apple Mail (2.1278)
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: Fri, 31 Aug 2012 16:17:53 -0000

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/