Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-summary-stat-03

Qin Wu <> Wed, 12 December 2012 07:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B791821F8202 for <>; Tue, 11 Dec 2012 23:02:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.319
X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=-2.473, BAYES_00=-2.599, GB_SUMOF=5, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W2t03V6pQKIO for <>; Tue, 11 Dec 2012 23:02:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 001A221F8455 for <>; Tue, 11 Dec 2012 23:02:49 -0800 (PST)
Received: from (EHLO ([]) by (MOS 4.3.5-GA FastPath queued) with ESMTP id ANT31764; Wed, 12 Dec 2012 07:02:45 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Dec 2012 07:01:53 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Dec 2012 07:02:42 +0000
Received: from w53375 ( by ( with Microsoft SMTP Server (TLS) id 14.1.323.3; Wed, 12 Dec 2012 15:02:35 +0800
Message-ID: <>
From: Qin Wu <>
To: Colin Perkins <>, "Romascanu, Dan (Dan)" <>
References: <> <>
Date: Wed, 12 Dec 2012 15:02:34 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: base64
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: []
X-CFilter-Loop: Reflected
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-summary-stat-03
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Metric Blocks for use with RTCP's Extended Report Framework working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Dec 2012 07:02:53 -0000

Hi, Colin:
Thank for your comments, please see my reply inline below.

----- Original Message ----- 
From: "Colin Perkins" <>
To: "Romascanu, Dan (Dan)" <>
Cc: <>
Sent: Wednesday, December 12, 2012 5:48 AM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-summary-stat-03

On 29 Nov 2012, at 13:55, Romascanu, Dan (Dan) wrote:
> This is a Working Group Last Call for  
> Please read and review this document, and send your comments, questions and concerns to the WG list before December 13, 2012. If you have no comments and you believe that the document is ready for submission to the IESG as a Standards Track document please send a short message as well to help us in determining the level of review and consensus. 

Section 3.2.2 of the draft cites draft-ietf-xrblock-rtcp-xr-discard and suggests that the gap discard rate is based on the value of DT=3 packets, but there was some discussion at IETF 85 about removing DT=3, since it’s redundant with the sum of DT=1 and DT=2. Was that discussion resolved?

[Qin]: I remembered you proposed in the meeting to remove DT=3, instead using the sum of DT=1 and DT=2 to calculate the total number of packet discard. But I am a little doubt after the meeting since the merit of keeping DT=3 is it will be more simple to know the total number of discard based on one instance of discard count block with DT=3 
however I am okay with your proposal now since it did cause redundance and introduce complexing to check if value of DT=3 equal to sum value of  DT=1 and DT=2.
So if the consensus is to remove DT=3 from draft-ietf-xrblock-rtcp-xr-summary-stat, instead, using sum of DT=1 and DT=2, I think we should also remove DT=3 from the draft-ietf-xrblock-rtcp-xr-discard, am I right?

Otherwise, I just had some minor comments:

- Section 3.2 references draft-ietf-xrblock-rtcp-xr-discard, which is not a burst/gap metric draft, in the context of burst/gap metrics. This is confusing, and it would help to separate the discussion of the burst/gap discard metrics from the reference to the non-burst/gap discard draft.

[Qin]: I believe you are right and will separate this from the 1st paragraph of  section 3.2.

- Section 4.1.2: the term “derivation frame” is unclear. 

[Qin]: It should be changed into "derived frame" to get consistent with Picture Type definition in the section 2.1.
We divide Picture type into "key frame" and "derived frame" 

- Section 5.2 is insufficient, and needs to be updated in a manner analogous to the other recent RTCP XR blocks.

[Qin]: Okay.
Colin Perkins

xrblock mailing list