[xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-06

Alissa Cooper <alissa@cooperw.in> Tue, 09 December 2014 00:55 UTC

Return-Path: <alissa@cooperw.in>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id B53301A1AC8 for <xrblock@ietfa.amsl.com>; Mon, 8 Dec 2014 16:55:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hnThQIgoIe8n for <xrblock@ietfa.amsl.com>; Mon, 8 Dec 2014 16:55:31 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F7F1A1A87 for <xrblock@ietf.org>; Mon, 8 Dec 2014 16:55:31 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.nyi.internal (Postfix) with ESMTP id 136B22078C for <xrblock@ietf.org>; Mon, 8 Dec 2014 19:55:31 -0500 (EST)
Received: from frontend1 ([]) by compute1.internal (MEProxy); Mon, 08 Dec 2014 19:55:31 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version; s=mesmtp; bh=s0hhsZaBCUg4dpWR0 TNEh9Nwbhw=; b=edWTCBc8d1h4ToeX2rTXRjzuYXcrdojUpyW6vWTMbrpPMJzRK YtVEj5Afzox5DKxZrBCyD/yLdlwOagyBjNKpVYZ2pwdwB0NLOscwmNKueGpyThvl OU8SYdUMhC+Y+pWQxc5fiigHCDBpqZFtz4+cLEis/nR0sXojZdxANj5nfE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:from:content-type :content-transfer-encoding:subject:message-id:date:to :mime-version; s=smtpout; bh=s0hhsZaBCUg4dpWR0TNEh9Nwbhw=; b=VuF 2XBhvzp1X14mNe5Za3Gc2BEhThJHQ7QZ/s623VzwE9lJ8oH9fTp6HDUqyfIGUniw HNNwJxZPjH8JOc3D0iFaZAtWnmElYjsXQc94W7GNCZe/I6H8JkUIPAkRF3wx0loq pkWgJPeO8ddd3X1n7L5iVtmm33jprXC7SkO7HzwA=
X-Sasl-enc: D8ypqU3fmjITv/dtctGduahUJJ6loLIIX1H7xFVcIOZo 1418086530
Received: from [] (unknown []) by mail.messagingengine.com (Postfix) with ESMTPA id AFF19C0027E for <xrblock@ietf.org>; Mon, 8 Dec 2014 19:55:30 -0500 (EST)
From: Alissa Cooper <alissa@cooperw.in>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Message-Id: <D32FC842-9A83-4D05-8509-FAACEE043A4A@cooperw.in>
Date: Mon, 08 Dec 2014 16:55:29 -0800
To: xrblock@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/Yl8AQSjCZ5sYuUqtZwItWiJZ7L8
Subject: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-06
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.15
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, 09 Dec 2014 00:55:34 -0000

I have reviewed this draft in preparation for IETF LC and I have some comments and questions before proceeding with the LC announcement.

= Section 3 =
"When comparing this metric
  with pre-repair loss metric of RTCP SR/RR, ambiguity may occur as
  noted in [RFC5725]: Some packets will not be repaired in current RTCP
  interval. Thus it is RECOMMENDED that this report block should be
  generated for those source packets that have no further chance of
  being repaired.”

The analogous text in RFC 5725 specifies both the recommended behavior and the behavior that is not recommended:

"To avoid any ambiguity in the evaluation, it is RECOMMENDED that the post-repair
  Loss RLE be generated for the source packets that have no further
  chance of being repaired.  If the loss-repair method(s) may still
  recover one or more missing source packets, the post-repair Loss RLE
  SHOULD NOT be sent until the loss-recovery process has been

It seems like this document should also specify what is not recommended, otherwise it seems a little vague. Another approach could be to say "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."

"But a potential ambiguity may result from sequence
  number range inconsistent. The sequence number range reported by RTCP
  SR/RR may contain some sequence numbers of packets for which repair
  might still be possible. To address this issue, we use begin sequence
  number and end sequence number to explicitly indicate the actual
  sequence number range that this RTCP XR report block reports on as
  the measurement timing.”

I don’t really understand what the stated ambiguity is here, or how it is addressed by including begin_seq and end_seq. As long as the “unrepaired loss count” field is defined as number of packets lost for which repair is no longer possible, what is inconsistent or ambiguous, and how does specifying the sequence number range change anything?

"Note that this metric must be measured in the primary source RTP packets.”

I’m not sure what this means.

= Appendix A =
Doesn’t it sort of defeat the purpose of the 6390 template to fill out a template with a bunch of links back to the definitions of the fields in other parts of the document, rather than putting those definitions directly in the template? I mean, isn’t the point of the template to have all of the information concisely reported in one place?

== Nits to be resolved with any IETF LC comments ==

= Section 1 =
RTCP SR/RR — expand SR/RR on first use

s/cumulative number of packet lost/cumulative number of packets lost/

s/a range of RTP application/a range of RTP applications/

The metrics defined in this document belongs to the class of
  transport-related metrics defined in [RFC6792]. And it is in
  accordance with the guidelines in [RFC6390] and [RFC6792].

The metrics defined in this document belong to the class of
  transport-related metrics defined in [RFC6792] and are specified in 
  accordance with the guidelines in [RFC6390] and [RFC6792].

= Section 3 =
s/in current RTCP interval/in the current RTCP interval/

= Section 4.2 =
s/for unilateral parameter/for unilateral parameters/