Re: [xrblock] [AVTCORE] Open issue- identity info repetition indraft-ietf-avtcore-monarch

Colin Perkins <csp@csperkins.org> Tue, 14 June 2011 10:27 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: xrblock@ietfa.amsl.com
Delivered-To: xrblock@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F36411E80EC for <xrblock@ietfa.amsl.com>; Tue, 14 Jun 2011 03:27:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.378
X-Spam-Level:
X-Spam-Status: No, score=-103.378 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SUBJECT_FUZZY_TION=0.156, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfMDq4TodRgd for <xrblock@ietfa.amsl.com>; Tue, 14 Jun 2011 03:27:12 -0700 (PDT)
Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by ietfa.amsl.com (Postfix) with ESMTP id 8F6FF11E8097 for <xrblock@ietf.org>; Tue, 14 Jun 2011 03:27:11 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1QWQoA-0003Va-jh; Tue, 14 Jun 2011 10:25:18 +0000
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Colin Perkins <csp@csperkins.org>
X-Priority: 3
In-Reply-To: <02fa01cc2753$a01c9ba0$46298a0a@china.huawei.com>
Date: Tue, 14 Jun 2011 11:25:17 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <74093E21-0A4F-4A55-B468-17631381F74D@csperkins.org>
References: <BANLkTi=5Qw4CRSWjwavU1_fcX2fOJHdVWw@mail.gmail.com> <02fa01cc2753$a01c9ba0$46298a0a@china.huawei.com>
To: Qin Wu <sunseawq@huawei.com>
X-Mailer: Apple Mail (2.1084)
Cc: xrblock@ietf.org
Subject: Re: [xrblock] [AVTCORE] Open issue- identity info repetition indraft-ietf-avtcore-monarch
X-BeenThere: xrblock@ietf.org
X-Mailman-Version: 2.1.12
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, 14 Jun 2011 10:27:13 -0000

Qin,

On 10 Jun 2011, at 10:49, Qin Wu wrote:
> Hi, Peter:
> Thank for your comments. Please see my following question below.
>> ----- Original Message -----
>> From: Peter Musgrave
>> To: sunseawq@huawei.com ; csp@csperkins.org ; xrblock@ietf.org
>> Sent: Monday, June 06, 2011 3:01 AM
>> Subject: Re: [AVTCORE] [xrblock] Open issue- identity info repetition indraft-ietf-avtcore-monarch
>> 
>> Hi Qin, Colin, 
>> 
>> I agree with Colin that the case for reducing identity inefficiency is not very compelling. These kinds of blocks are not sent as frequently as e.g. the RTP payload and in general a number of XR blocks can be stacked in one MTU with ease.
>>  
> [Qin]: Yes, such block is not sent frequently. Suppose we separate identity block out from each metric block and allow identity block only being sent once at the start of session, is it compelling to have such independent identity block?

I don't think so. If we have an identity block, it should be sent following the usual RTCP schedule.

>> Hence I would suggest we not incur the protocol and implementation complexity of having identity blocks and references to them etc. 
>>  
> [Qin]: I agree that it is not compelling to let each small metric block to reference the independent identity block with identity information included if each metric block already have SSRC and support such reference. However it looks to me measure information defined in measurement identity block of draft-ietf-avt-rtcp-xr-meas-identity-02 contain more than SSRC which could be used as the key to look up other application specific information, e.g., diagonose information. So it will be good to still have identity block.

It might be good to have some of the other information contained in the Identity Block, and a new block type could be defined to convey that. The identity block, and the idea of a tag to correlate it with other blocks, doesn't seem useful though.

-- 
Colin Perkins
http://csperkins.org/