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

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Thu, 20 December 2012 09:36 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 5449921F86A5 for <xrblock@ietfa.amsl.com>; Thu, 20 Dec 2012 01:36:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.419
X-Spam-Level:
X-Spam-Status: No, score=-103.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 M4MKQPlKsJZj for <xrblock@ietfa.amsl.com>; Thu, 20 Dec 2012 01:36:22 -0800 (PST)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 031ED21F8654 for <xrblock@ietf.org>; Thu, 20 Dec 2012 01:36:21 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAKUvoFCHCzI1/2dsb2JhbABEgmzAaYEIgh4BAQEBAwEBAQ8LHTQXBAIBCA0BAwEDAQELFAkHIQYLFAMGCAIEARIIARIHh1YDDwEKniaSHw2JVIssaYVpYQOUJgGHYoUlhRGCb4IZ
X-IronPort-AV: E=Sophos;i="4.80,759,1344225600"; d="scan'208";a="337130204"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 20 Dec 2012 04:29:32 -0500
Received: from unknown (HELO AZ-FFEXHC01.global.avaya.com) ([135.64.58.11]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 20 Dec 2012 04:11:49 -0500
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC01.global.avaya.com ([135.64.58.11]) with mapi id 14.02.0318.004; Thu, 20 Dec 2012 04:36:19 -0500
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Qin Wu <bill.wu@huawei.com>, Roni Even <ron.even.tlv@gmail.com>, "xrblock@ietf.org" <xrblock@ietf.org>
Thread-Topic: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02
Thread-Index: AQFQjZvMYLqHDMrRdEtJf889psq3PZkauECAgADXGl+AAMWkgP//uNcpgAABkuA=
Date: Thu, 20 Dec 2012 09:36:18 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA044810@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> <8C09D242D355466AB1C11927D3719EFF@china.huawei.com>
In-Reply-To: <8C09D242D355466AB1C11927D3719EFF@china.huawei.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:36:23 -0000

(speaking as a contributor)

Solution (a) seems to me closer to the 'philosophy' we adopted with the modular monitoring architecture. 

Regards,

Dan




> -----Original Message-----
> From: Qin Wu [mailto:bill.wu@huawei.com]
> Sent: Thursday, December 20, 2012 11:29 AM
> To: Roni Even; Romascanu, Dan (Dan); xrblock@ietf.org
> Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-decodability-02
> 
> Hi, Roni:
> We have two ways:
> (a) If we choose to define a second report block later, we also need to
> change  the current block name from "The MPEG-TS Decodability Metrics
> Block"
> to "The MPEG-TS PSI Independent Decodability Metrics Block" to avoid
> block name confusing.
> 
> (b) If we choose to take all PSI related parameters into the current
> block, we don't need to change block name but block length will grow
> into 17 from 11.
> 
> If people don't think the block size growth is a problem, I perfer the
> (b).
> 
> Regards!
> -Qin
> ----- Original Message -----
> From: "Roni Even" <ron.even.tlv@gmail.com>
> To: "'Qin Wu'" <bill.wu@huawei.com>om>; "'Romascanu, Dan (Dan)'"
> <dromasca@avaya.com>om>; <xrblock@ietf.org>
> Sent: Thursday, December 20, 2012 4:44 PM
> 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
> >>
> >