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

[Gonzalo Camarillo <[e-mail]>]

Hi Alan,

thanks. I have just put this draft on the agenda of the May 30th telechat.

Cheers,

Gonzalo

On 16/05/2013 12:28 PM, Alan Clark wrote:
> 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).
>>>>>
>>>>>
>>>>>
>>>>
>>
> 
>