Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Thu, 20 December 2012 09:24 UTC

Return-Path: <dromasca@avaya.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 3D2BE21F86CB for <xrblock@ietfa.amsl.com>; Thu, 20 Dec 2012 01:24:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.414
X-Spam-Level:
X-Spam-Status: No, score=-103.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 p33M3NmQw3D3 for <xrblock@ietfa.amsl.com>; Thu, 20 Dec 2012 01:23:59 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 6635621F8623 for <xrblock@ietf.org>; Thu, 20 Dec 2012 01:23:59 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgIFAIbQt1DGmAcF/2dsb2JhbABEgmy9GRZzgh4BAQEBAwEBAQ8LHTQXBAIBCA0BAwEDAQELFAkHIQYLFAMGCAIEARIIARmHXAMPAQuhe5MrDYlUi1dpg2BhA5QrAYdihSeFEIJygiE
X-IronPort-AV: E=Sophos;i="4.84,186,1355115600"; d="scan'208";a="381512995"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 20 Dec 2012 04:14:57 -0500
Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by co300216-co-erhwest-out.avaya.com with ESMTP; 20 Dec 2012 04:20:45 -0500
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 04:23:59 -0500
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Roni Even <ron.even.tlv@gmail.com>, 'Qin Wu' <bill.wu@huawei.com>, "xrblock@ietf.org" <xrblock@ietf.org>
Thread-Topic: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02
Thread-Index: AQFQjZvMYLqHDMrRdEtJf889psq3PZkauECAgADXGl+AAMWkgP//tvCA
Date: Thu, 20 Dec 2012 09:23:57 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA0447FB@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA024828@AZ-FFEXMB04.global.avaya.com> <03ed01cdddea$abe24170$03a6c450$@gmail.com> <E9065C5941FE44C98930D6DE8A896F48@china.huawei.com> <046a01cdde8e$34df8ac0$9e9ea040$@gmail.com>
In-Reply-To: <046a01cdde8e$34df8ac0$9e9ea040$@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.45]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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:24:00 -0000

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>om>; <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
> >