Re: [pm-dir] =?Big5?B?tarOYA==?=: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability

[Alan Clark <[e-mail]>]

I am satisfied with the revisions

Regards

Alan


On 5/15/13 11:45 AM, "Al Morton" <[e-mail]> wrote:

> Alan, 
> Since you reviewed this draft, are you satisfied with the revisions?
> Al
> 
>> -----Original Message-----
>> From: Gonzalo Camarillo [mailto:[e-mail]]
>> Sent: Wednesday, May 15, 2013 11:21 AM
>> To: Qin Wu
>> Cc: Benoit Claise; Alan Clark; [e-mail]; Dan (Dan); Shida Schubert;
>> Huangyihong (Rachel); [e-mail]; [e-mail]; MORTON JR.,
>> ALFRED C (AL)
>> Subject: Re: 答复: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>> 
>> Hi Benoit,
>> 
>> what is the status of this? Can I progress this draft at this point?
>> 
>> Thanks,
>> 
>> Gonzalo
>> 
>> On 11/04/2013 5:14 AM, Qin Wu wrote:
>>> Hi,Benoit:
>>> As Alan observed in PM-DIR review, this draft does not define new
>> metrics but refers to metrics that are
>>> clearly defined in a normative reference.
>>> I think we can skip RFC6390 template usage just like PDV draft(RFC6798)
>> did, can't we?
>>> 
>>> Regards!
>>> -Qin
>>> -----邮件原件-----
>>> 发件人: Benoit Claise [mailto:[e-mail]]
>>> 发送时间: 2013年4月10日 21:53
>>> 收件人: Qin Wu
>>> 抄送: Alan Clark; Gonzalo Camarillo; [e-mail]; Dan (Dan); Shida
>> Schubert; Huangyihong (Rachel); [e-mail]; [e-mail]; Al
>> Morton
>>> 主题: Re: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>>> 
>>> Hi Qin,
>>> 
>>> And don't forget the RFC 6390 template usage.
>>> 
>>> Regards, Benoit
>>>> Hi, Alan:
>>>> Thank for your valuable comments.
>>>> We have updated the draft to incorporate your comments in the new
>> version (-v11).
>>>> The diff is:
>>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-xrblock-rtcp-xr-
>> decodability-11
>>>> Please also see my reply below.
>>>> 
>>>> Regards!
>>>> -Qin
>>>> ----- Original Message -----
>>>> From: "Alan Clark" <[e-mail]>
>>>> To: "Gonzalo Camarillo" <[e-mail]>; <pm-
>> [e-mail]>; "Benoit Claise" <[e-mail]>; "Dan (Dan)"
>> <[e-mail]>; "Shida Schubert" <[e-mail]>;
>> <[e-mail]>; <[e-mail]>; <[e-mail]>;
>> <[e-mail]>; "Al Morton" <[e-mail]>
>>>> Sent: Saturday, April 06, 2013 3:10 AM
>>>> Subject: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability
>>>> 
>>>> 
>>>> There are quite a few issues with the draft - I can re-review as soon
>> as
>>>> these are addressed.
>>>> 
>>>> Alan Clark
>>>> 
>>>> 
>>>> 
>>>> A. General Comments
>>>> 
>>>> This draft does not define new metrics but refers to metrics that are
>>>> clearly defined in a normative reference.  The normative reference
>> (ETSI
>>>> TR101290) predates RFC6390 however does contain a fairly clear
>> description
>>>> of the metrics with explanation of their usage. It is not recommended
>> that
>>>> this draft redefines the metrics in RFC6390 template form
>>>> 
>>>> [Qin]: Exactly.
>>>> 
>>>> however there is
>>>> considerable scope for improvement in the clarity of definition of how
>> these
>>>> metrics are used.
>>>> 
>>>> [Qin]: Agree.
>>>> 
>>>> B. Applicability Section
>>>> 
>>>> 1.4 Applicability
>>>> Metrics only measure transport stream quality not content stream
>> quality.
>>>> Also the metrics are not defined in this draft but are encodings of the
>>>> metrics defined in ETSI TS 101290.
>>>> 
>>>> Suggest
>>>> 
>>>> ³This block type allows a counts of MPEG Transport Stream quality
>> metrics
>>>> that are measured in accordance with ETSI TR 101290 [ETSI] to be
>> reported by
>>>> an endpoint.  These metrics are useful for identifying bitstream
>>>> packetization and transport stream encoding problems that may affect
>> the
>>>> user¹s perception of a video service delivered over RTP.²
>>>> 
>>>> [Qin]: Okay. Your proposed text have been incorporated in (-v11).
>>>> 
>>>> C. Metrics Definitions
>>>> 
>>>> C.1 General
>>>> 
>>>> For clarity the draft should preface the metrics definitions with a
>> general
>>>> explanation of how these metrics relate to ETSI TR101290. TR101290
>> generally
>>>> defines error events and this draft contains counts of those metrics.
>>>> 
>>>> 
>>>> If there are any ³edge² cases where a problem in one measurement
>> interval
>>>> would be reflected in the count in the next measurement interval then
>> this
>>>> should be articulated in the general description and also in the
>> specific
>>>> metric.  For example, a sync byte error is defined as multiple
>> consecutive
>>>> errored sync bytes and if this was reported in an interval it may have
>>>> occurred at the end of the preceding interval or at some time during
>> the
>>>> present interval - hence the description should state that the count
>> may
>>>> reflect a problem in the current or previous interval. This would also
>> be
>>>> the case for PCR errors and even continuity count errors.
>>>> 
>>>> [Qin]: Okay, I have added some text in the 2nd paragraph of section 3
>>>> and incorporated your suggested text in (v-11).
>>>> 
>>>> C.2  Sequence numbers
>>>> 
>>>> begin_seq and end_seq
>>>> 
>>>> These definitions simply say ³As defined inS² which requires the reader
>> to
>>>> refer to another document. It is good practice to at least mention what
>> the
>>>> definition refers to and then to include a reference that contains the
>>>> normative definition.
>>>> 
>>>> SoS..
>>>> 
>>>> ³begin_seq: 16 bits
>>>> 
>>>> The RTP sequence number corresponding to the start of the measurement
>>>> period, as defined in Section 4.1 of RFC 3611²
>>>> 
>>>> [Qin]: Fixed in (-v11).
>>>> 
>>>> C.3 Metrics definitions
>>>> The metrics definitions should contain a firmer statement of what is
>> being
>>>> measured and, if the normative definition is in another standard, then
>>>> clearly state ³as defined in Section X.Y of NNNNN². This applies to all
>> the
>>>> metrics definitions and the example below can be used as a template for
>>>> 
>>>> For example
>>>> 
>>>> Existing language S..
>>>> 
>>>> TS_sync_loss_count: 32 bits
>>>> 
>>>> Number of TS_sync_loss errors in the above sequence number interval.
>> It is
>>>> calculated based on the occurrence of errors for
>> "TS_sync_loss"parameter
>>>> defined in the section 5.2.1 of [ETSI] (Also see section 5.5.1 of
>> [ETSI]).
>>>> 
>>>> This is very vague language and it is unclear why the ³Also see²
>> reference
>>>> is there.  A better approach is:
>>>> 
>>>> Replacement language (use this format for each of the metrics)
>>>> 
>>>> TS_sync_loss_count: 32 bits
>>>> 
>>>> A count of the number of TS_sync_loss errors that occurred in the above
>>>> sequence number interval.  A TS_sync_loss error occurs when there are
>> two or
>>>> more consecutive incorrect sync bytes within the MPEG TS stream, as
>> defined
>>>> in section 5.2.1 of [ETSI]. This parameter may be used as part of a
>> Service
>>>> Availability calculation, as defined in section 5.5.1 of [ETSI].
>>>> 
>>>> [Qin]: Fixed in (-v11).
>>>> 
>>>> C.4 Service Availability
>>>> 
>>>> Following on from the previous comment,  section 5.5.1 of TR101290
>> describes
>>>> a service availability error as a combination of TS_sync_loss,
>> PAT_error and
>>>> PMT_error whereas draft-ietf-xrblock-rtcp-xr-decodability-10 does not
>>>> contain the PAT and PMT error metrics.  The resolution for this would
>> either
>>>> be to remove the reference to 5.5.1 or to add the metrics required to
>>>> calculate the service availability.
>>>> 
>>>> [Qin]: Agree. I prefer to remove the reference to 5.5.1 since there was
>> consensus in the past WGLC to this draft
>>>> that having a second report block later to cover the other parameters
>> and get inline with concept of RFC6792
>>>> and letting this draft focus on PSI indpendent parameter reporting.
>>>> See details for the WGLC discussion in the following link:
>>>> http://www.ietf.org/mail-archive/web/xrblock/current/msg01032.html
>>>> 
>>>> It is recommended that PAT_error , PAT_error_2,  PMT_error and
>> PMT_error_2
>>>> be included as metrics as these ³are² generally present in MPEG
>> Transport
>>>> streams and errors within these can prevent correct decoding of the
>> stream.
>>>> 
>>>> C.5 PCR_error_count
>>>> 
>>>> PCR_error_count is defined twice - the second of these should be
>>>> PCR_accuracy_error_count
>>>> 
>>>>   [Qin]: Good catch and have fixed in (-v11).
>>>> 
>>>> 
>>>> 
>>> 
>