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

Glen Zorn <> Wed, 12 December 2012 07:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E36A321F8D52 for <>; Tue, 11 Dec 2012 23:08:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.935
X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[AWL=-2.336, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8KbjteJJTEHR for <>; Tue, 11 Dec 2012 23:08:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E26B021F8CB0 for <>; Tue, 11 Dec 2012 23:08:06 -0800 (PST)
Received: by with SMTP id uo1so282153pbc.31 for <>; Tue, 11 Dec 2012 23:08:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=U/qSPbITovCELFRm8HoiPZrypMosYWqZLswvph+bT44=; b=SIJxes2C6OjGGIwGE4pFqBl2DNBkTDRe3EHzihfdWqCWPPe6iY+AnQs7hwWIRdqg/D 3EEuom9XD8WPSmPB1Q1CIHZ0+5AoyzE3Mp/JpXeqtJ7i/J3ZwJyO0RLSAq6Nl6Nx2okT 8K1QavBAkVbyhnUWKoocXvlAzDBnGNdCiHlELU26vmmtBy0C2RVcrOYsGNVNJm2wfg8m aXYnynXbE8j/AmlTl+YmpmKy/m0AU07H8YI2q71febsmf1taC+2UGJPsMZkDkwOY38lo YXJm5tZx8fF16q5pUl6Kx5A7rUA/bD6MRakGOWqqGtNyOfSO+JDqm36lhy98n2ewwkp6 UIkQ==
Received: by with SMTP id pr3mr27655pbb.151.1355296086518; Tue, 11 Dec 2012 23:08:06 -0800 (PST)
Received: from [] ( []) by with ESMTPS id oi3sm15172678pbb.1.2012. (version=SSLv3 cipher=OTHER); Tue, 11 Dec 2012 23:08:05 -0800 (PST)
Message-ID: <>
Date: Wed, 12 Dec 2012 14:08:01 +0700
From: Glen Zorn <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Colin Perkins <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Cc: "" <>
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:08:08 -0000

On 12/12/2012 04:48 AM, Colin Perkins wrote:
> 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?

In order for this metric to be meaningful, exactly one of the following 
conditions must hold:

  * the packet contains a block with DT=3


  * the packet contains 2 blocks with DT=1 and DT=2, respectively

If we are going to force the latter in this case, is there any argument 
for keeping DT=3 in the other draft?

Personally, if we include DT=3 in draft-ietf-xrblock-rtcp-xr-discard, I 
would like the flexibility to use it here - saves space, etc.

> 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.

I believe that the reference is in the context of /discards/, not 
burst/gap metrics and is completely appropriate.  If you found it 
confusing, can you suggest a better wording?

> 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.
> - Section 4.1.2: the term “derivation frame” is unclear.

Maybe a reference would help?

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

Can you be a bit more specific?