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

"Alissa Cooper (alcoop)" <alcoop@cisco.com> Tue, 09 December 2014 00:41 UTC

Return-Path: <alcoop@cisco.com>
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 9DF151A1A63 for <xrblock@ietfa.amsl.com>; Mon, 8 Dec 2014 16:41:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id tEcZjgBF8q35 for <xrblock@ietfa.amsl.com>; Mon, 8 Dec 2014 16:41:57 -0800 (PST)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEF931A1A43 for <xrblock@ietf.org>; Mon, 8 Dec 2014 16:41:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4459; q=dns/txt; s=iport; t=1418085717; x=1419295317; h=from:to:subject:date:message-id:mime-version; bh=wVpceTiAUctwwNjmnDw05cGyHJLs0L6DC4QqZPWNXRI=; b=RboA3PpQVbNbZ1vYKrKDQTpv8fzHGdNFiFrWC8KAt+i9hSaJ+zsyCZ0x AcnHJaFUJiXsrfprwSPvajG4BVsfaKmVE52bBXJdOJTtVRZqnfdw0ePA6 aq6tNDqtsXqiVl/K8zesjV74JNwzMpda687PuNCtxqRlRNU4CadVGyEc7 g=;
X-Files: signature.asc : 496
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.07,541,1413244800"; d="asc'?scan'208";a="378610296"
Received: from rcdn-core-7.cisco.com ([]) by rcdn-iport-8.cisco.com with ESMTP; 09 Dec 2014 00:41:30 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com []) by rcdn-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id sB90fIYr003617 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <xrblock@ietf.org>; Tue, 9 Dec 2014 00:41:18 GMT
Received: from xmb-rcd-x09.cisco.com ([]) by xhc-aln-x03.cisco.com ([]) with mapi id 14.03.0195.001; Mon, 8 Dec 2014 18:41:18 -0600
From: "Alissa Cooper (alcoop)" <alcoop@cisco.com>
To: "xrblock@ietf.org" <xrblock@ietf.org>
Thread-Topic: AD evaluation: draft-ietf-xrblock-rtcp-xr-post-repair-loss-count-06
Thread-Index: AQHQE0jXU0JYi1PGDkqOIH2KoF3UiQ==
Date: Tue, 09 Dec 2014 00:41:17 +0000
Message-ID: <67173649-B36F-43C8-AED2-5AF620E456DC@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
x-originating-ip: []
Content-Type: multipart/signed; boundary="Apple-Mail=_8CD0A43C-94AD-45DA-9EC4-C9F7274E1072"; protocol="application/pgp-signature"; micalg="pgp-sha512"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/xrblock/89tlgb5JviW1Beh2XJt9Lj2WGxU
X-Mailman-Approved-At: Tue, 09 Dec 2014 03:32:49 -0800
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:41:59 -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/