Re: [pm-dir] 答复: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability

[Gonzalo Camarillo <[e-mail]>]

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]>; <[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).
>>
>>
>>
>