[xrblock] Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and COMMENT)

"Benoit Claise" <bclaise@cisco.com> Tue, 06 January 2015 17:42 UTC

Return-Path: <bclaise@cisco.com>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC5A31A1A55; Tue, 6 Jan 2015 09:42:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxlEWOMTqkOa; Tue, 6 Jan 2015 09:42:55 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E676D1A1A31; Tue, 6 Jan 2015 09:42:54 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benoit Claise <bclaise@cisco.com>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 5.10.0.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150106174254.24975.89051.idtracker@ietfa.amsl.com>
Date: Tue, 06 Jan 2015 09:42:54 -0800
Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/Q1W0qPOuB-ZguqZ9edGaDSXHg8k
Cc: xrblock-chairs@tools.ietf.org, xrblock@ietf.org, draft-ietf-xrblock-rtcp-xr-post-repair-loss-count.all@tools.ietf.org
Subject: [xrblock] Benoit Claise's Discuss on draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: (with DISCUSS and COMMENT)
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.15
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, 06 Jan 2015 17:42:58 -0000

Benoit Claise has entered the following ballot position for
draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-post-repair-loss-count/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

1. post-repair loss count: 16 bits

      Total number of packets finally lost after applying one or more
      loss-repair methods, e.g., FEC and/or retransmission, during the
      actual sequence number range indicated by begin_seq and end_seq.
      This metric MUST NOT count the lost packets for which repair might
      still be possible. Note that this metric MUST measure only primary
      source RTP packets.

I see the MUST above, and the RECOMMENDED below.

   Thus it is RECOMMENDED that this report block should be generated
   only for those source packets that have no further chance of being
   repaired and not for any other packets. This block needs to specify
   its own measurement period to avoid ambiguity in calculating the
   post-repair loss count.

I was expecting a MUST instead of RECOMMENDED.
Did the WG discuss that point? 
In which situation would you need this exception, and what could you
actually deduce if you apply it?


2. Question:
   The relationship
   between the metrics in this report block and the pre-repair loss
   metric of RTCP XR could be expressed in the following formula:

      cumulative number of packets lost = post-repair loss count +
      repaired loss count + to be repaired lost packet

   "cumulative number of packets lost" is the metric from RTCP SR/RR.
   "post-repair loss count" and "repaired loss count" are the metrics
   defined in this draft.

Am I correct that it's difficult (if not impossible) to compare those
values with a small granularity because:
1. RFC 3550 section 6.4.1 SR: Sender Report RTCP Packet sends the
"cumulative number of packets lost" with timestamps
2. draft-ietf-xrblock-rtcp-xr-post-repair-loss-count sends "post-repair
loss count" and "repaired loss count" with sequence numbers.
On top of that, the intervals are different!


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- The abstract mentions:
   This document defines an RTP Control Protocol (RTCP) Extended Report
   (XR) Block that allows reporting of post-repair loss count metrics
   for a range of RTP applications.

This draft introduces two metrics: post-repair loss count and repaired
loss count
This is slightly confusing. 
I believe you want to include the two metrics in the abstract.
Alternatively:
NEW:
   This document defines an RTP Control Protocol (RTCP) Extended Report
   (XR) Block that allows reporting of post-repair loss-related metrics
   for a range of RTP applications.


-
   In
   addition,  another metric, repaired loss count, is also introduced in
   this report block for calculating the pre-repair loss count during
   the this range, 

the this -> chose one.