Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02
Qin Wu <bill.wu@huawei.com> Thu, 20 December 2012 09:36 UTC
Return-Path: <bill.wu@huawei.com>
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 D3A9921F8654 for <xrblock@ietfa.amsl.com>; Thu, 20 Dec 2012 01:36:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.712
X-Spam-Level:
X-Spam-Status: No, score=-4.712 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4]
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 CKnC5KNmOZdf for <xrblock@ietfa.amsl.com>; Thu, 20 Dec 2012 01:36:54 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 626D521F8651 for <xrblock@ietf.org>; Thu, 20 Dec 2012 01:36:53 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AOA03028; Thu, 20 Dec 2012 09:36:52 +0000 (GMT)
Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 09:36:23 +0000
Received: from SZXEML412-HUB.china.huawei.com (10.82.67.91) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 09:36:28 +0000
Received: from w53375 (10.138.41.149) by szxeml412-hub.china.huawei.com (10.82.67.91) with Microsoft SMTP Server (TLS) id 14.1.323.3; Thu, 20 Dec 2012 17:36:21 +0800
Message-ID: <FC1AB14292A545D6991206EB72540594@china.huawei.com>
From: Qin Wu <bill.wu@huawei.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, Roni Even <ron.even.tlv@gmail.com>, xrblock@ietf.org
References: <9904FB1B0159DA42B0B887B7FA8119CA024828@AZ-FFEXMB04.global.avaya.com> <03ed01cdddea$abe24170$03a6c450$@gmail.com> <E9065C5941FE44C98930D6DE8A896F48@china.huawei.com> <046a01cdde8e$34df8ac0$9e9ea040$@gmail.com> <9904FB1B0159DA42B0B887B7FA8119CA0447FB@AZ-FFEXMB04.global.avaya.com>
Date: Thu, 20 Dec 2012 17:36:20 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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: [10.138.41.149]
X-CFilter-Loop: Reflected
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02
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: Thu, 20 Dec 2012 09:36:54 -0000
Not need, we have text in the draft to say the parameters we get are gathered from TS header. But If we choose to add PSI related parameter into the current block, we should change "the parametes are gathered from TS header" into something like "the parametes are gathered from TS packet" Regards! -Qin ----- Original Message ----- From: "Romascanu, Dan (Dan)" <dromasca@avaya.com> To: "Roni Even" <ron.even.tlv@gmail.com>; "'Qin Wu'" <bill.wu@huawei.com>; <xrblock@ietf.org> Sent: Thursday, December 20, 2012 5:23 PM Subject: RE: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02 I agree as well. The only question I have is whether we should add more detailed text to explain the choice, on the line of the explanation given by Qin. Thanks and Regards, Dan > -----Original Message----- > From: Roni Even [mailto:ron.even.tlv@gmail.com] > Sent: Thursday, December 20, 2012 10:44 AM > To: 'Qin Wu'; Romascanu, Dan (Dan); xrblock@ietf.org > Subject: RE: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02 > > Hi Qin, > Thanks for the explanation. I see no problem with the current > parameters. I assume that we can define later a second report block > that will cover the other parameters and it will be inline with the > concepts of the monitoring architecture Roni > > -----Original Message----- > From: Qin Wu [mailto:bill.wu@huawei.com] > Sent: 20 December, 2012 3:57 AM > To: Roni Even; 'Romascanu, Dan (Dan)'; xrblock@ietf.org > Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02 > > Hi, Roni: > Thank for raising this issue. > In this draft, we are not choosing to report all indications in the > first priority and second priority. Instead, we are choosing to report > all the parameters that can be easily gathered by parsing the TS header. > What we ignore is all the other PSI/SI related parameters in the first > priority and second priority. These parameters usually fixs and repeatly > occur in the received stream and need deep parsing not only TS header > but also TS payload which introduce complexity in the test and > measurment instrument. However I do agree with you these PSI/SI related > parameters are still very important parameters. Any error of these > PSI/SI related parameters will lead to very serious quality problem. > > Regarding the option you proposed, I am not favoring the second approach > since it doesn't solve the problem you raised and we already clarified > the parameter we are taking belong to 1st and 2nd prioirty in the > description before the format. I checked section 5.3.5 of TR 101.290, > which provide TS parameters in transmission system with "reduced SI > data". I think if we really want to take some new parameters, we like to > choose to take additional missing parameters in the 1st and 2nd priority > of section 5.3.5, which belong to "reduced SI data". > > Otherwise we prefer to leave as it is. > > Regards! > -Qin > ----- Original Message ----- > From: "Roni Even" <ron.even.tlv@gmail.com> > To: "'Romascanu, Dan (Dan)'" <dromasca@avaya.com>; <xrblock@ietf.org> > Sent: Wednesday, December 19, 2012 9:13 PM > Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02 > > > > Hi, > > Sorry for the late posting. > > I noticed that ETSI TR 101 290 has eight first priority and eight > > second priority indications (section 5.2.1 and 5.2.2) while here we > > list only > half > > of them claiming that the others do not apply to all MPEG > implementations. > > > > > > > I do not have a major problem with keeping the XR block as is but we > > can look at two other options. > > > > 1. Have all 16 indications. > > 2 Add two new parameters " # of First Priority Errors" and "# of > Second > > Priority Errors " > > > > Roni Even > > > > -----Original Message----- > > From: xrblock-bounces@ietf.org [mailto:xrblock-bounces@ietf.org] On > > Behalf Of Romascanu, Dan (Dan) > > Sent: 29 November, 2012 2:48 PM > > To: xrblock@ietf.org > > Subject: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02 > > > > > > This is a Working Group Last Call for > > http://www.ietf.org/id/draft-ietf-xrblock-rtcp-xr-decodability-02.txt. > > > > 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. > > > > Thanks and Regards, > > > > Dan > > > > > > > > _______________________________________________ > > xrblock mailing list > > xrblock@ietf.org > > https://www.ietf.org/mailman/listinfo/xrblock > > > > _______________________________________________ > > xrblock mailing list > > xrblock@ietf.org > > https://www.ietf.org/mailman/listinfo/xrblock > >
- [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decod… Romascanu, Dan (Dan)
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Ali C. Begen (abegen)
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Qin Wu
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Colin Perkins
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Glen Zorn
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Qin Wu
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Colin Perkins
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Romascanu, Dan (Dan)
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Huangyihong (Rachel)
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Roni Even
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Qin Wu
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Roni Even
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Romascanu, Dan (Dan)
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Qin Wu
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Romascanu, Dan (Dan)
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Qin Wu
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Qin Wu
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Romascanu, Dan (Dan)
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Colin Perkins
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Roni Even
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Qin Wu
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Claire Bi(jiayu)
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Huangyihong (Rachel)
- Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-d… Qin Wu