IETF Logo Mail Archive

Re: [AVTCORE] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt

Qin Wu <sunseawq@huawei.com> Fri, 10 June 2011 08:55 UTC

Return-Path: <sunseawq@huawei.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BF411E80DC; Fri, 10 Jun 2011 01:55:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599]
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 HkLLbBVbs5iX; Fri, 10 Jun 2011 01:55:01 -0700 (PDT)
Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by ietfa.amsl.com (Postfix) with ESMTP id A143511E8092; Fri, 10 Jun 2011 01:55:00 -0700 (PDT)
Received: from huawei.com (szxga05-in [172.24.2.49]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMK0089FGRN9L@szxga05-in.huawei.com>; Fri, 10 Jun 2011 16:54:59 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga05-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LMK00KR3GRMMO@szxga05-in.huawei.com>; Fri, 10 Jun 2011 16:54:58 +0800 (CST)
Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LMK00BRGGRL7V@szxml06-in.huawei.com>; Fri, 10 Jun 2011 16:54:58 +0800 (CST)
Date: Fri, 10 Jun 2011 16:59:35 +0800
From: Qin Wu <sunseawq@huawei.com>
To: Colin Perkins <csp@csperkins.org>
Message-id: <029f01cc274c$b8fe19c0$46298a0a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664
X-Mailer: Microsoft Outlook Express 6.00.2900.3664
Content-type: text/plain; charset="ISO-8859-1"
Content-transfer-encoding: 7bit
X-Priority: 3
X-MSMail-priority: Normal
References: <01c501cc1c16$ebad8ea0$46298a0a@china.huawei.com> <BFEA47ED-8F65-476A-BBD4-D369493B9D22@csperkins.org>
Cc: magnus.westerlund@ericsson.com, avt@ietf.org, xrblock@ietf.org
Subject: Re: [AVTCORE] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jun 2011 08:55:02 -0000

Hi,
----- Original Message ----- 
From: "Colin Perkins" <csp@csperkins.org>
To: "Qin Wu" <sunseawq@huawei.com>
Cc: <avt@ietf.org>; <xrblock@ietf.org>; <magnus.westerlund@ericsson.com>
Sent: Thursday, June 09, 2011 9:58 PM
Subject: Re: [AVTCORE] Fw: I-D Action: draft-ietf-avtcore-monarch-02.txt


On 27 May 2011, at 03:36, Qin Wu wrote:
> This version addresses the open issues regarding identity information repetition and acknowledge section.
> http://www.ietf.org/internet-drafts/draft-ietf-avtcore-monarch-02.txt
> 
> The diff is:
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-avtcore-monarch-02
> 
> Comments are welcome!

This helps, but to my mind doesn't go far enough. We have the SSRC to identify participants. I don't see much benefit from having a separate identity tag in XR blocks.

[Qin]:  I think that we are talking about how to define future RTCP XR Block. 
It seems to me the rule we are following  to define the new RTCP XR BLock in the avtcore-monarch is a little different from the rule of we are doing to the existing RTCP XR described in RFC3611.

As for the existing XR Block defined in RFC3611, each of the existing XR Block has allocated  a field for SSRC of source. However such identity information can be 
repeated several times if several metric blocks reporting one stream from one source  is carried in the same RTCP Packet.

In order to reduce overhead to carry duplicated SSRC of source in each metric block,  in the new XR Block, we separate such SSRC of source out from each metric block.

One way is to  allocate identity tag field in each metric block which can be used to tell which metric block report on stream from which source. 

Another way is to follow the existing rules defined in RFC3611.
put back the SSRC of source field into each metric block which also can be used to tell which metric block report on stream from which source. 
However this rule seems to contradict to the rule of reducing identity information repetition discussed in avtcore-monarch.

Which way we should follow?


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

v2.14.0 | Report a Bug | By Email