Subject: Re: [pm-dir] Request for an RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability

From: "MORTON JR., ALFRED C (AL)" <[email-masked]>
Date: Wed, 3 Apr 2013 08:28:58 -0400

Hi Gonzalo, (revising the subject line)

Alan Clark has volunteered to conduct that review of
draft-ietf-xrblock-rtcp-xr-decodability

Alan, can you complete the review in a timely fashion?

Al

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Gonzalo Camarillo
> Sent: Wednesday, April 03, 2013 8:22 AM
> To: Benoit Claise
> Cc: [email-masked]; [email-masked]; Dan (Dan); Varun Singh; Shida
> Schubert; [email-masked]
> Subject: Re: [pm-dir] Request for an RFC6390 review of draft-ietf-xrblock-
> rtcp-xr-discard-rle-05
> 
> Hi,
> 
> out of the three drafts Benoit mentioned below, if we could get the
> following draft reviewed sooner rather than later, that would be great:
> 
>   draft-ietf-xrblock-rtcp-xr-decodability
> 
> The thing is that it has already passed its IETF LC and I would like to
> get the IESG to evaluate it in the near future if possible. However, I
> would like to get this review before sending it to the IESG.
> 
> Unless I have missed the review somehow...
> 
> Thanks,
> 
> Gonzalo
> 
> On 22/03/2013 11:17 AM, Benoit Claise wrote:
> > Dear pm-dir,
> >
> > Any taker? I sent a couple of requests recently.
> >      draft-ietf-xrblock-rtcp-xr-discard-rle-05
> >      draft-ietf-xrblock-rtcp-xr-discard-11
> >     draft-ietf-xrblock-rtcp-xr-decodability
> >
> > Those drafts are in the Waiting for AD Go-Ahead. So it's about time.
> >
> > Regards, Benoit
> >> Dear pm-dir,
> >>
> >> Who is able to help with this review?
> >> Note: Alan, Brian, Al, Dan, and I have been taking a couple of drafts
> >> today during our meeting at the IETF.
> >>
> >> Regards, Benoit
> >>> Hi Benoit;
> >>>
> >>>   This is Shida, a co-chair of XRBLOCK WG.
> >>>
> >>>   Based on the discussion yesterday, I am requesting
> >>> review of the following draft to be reviewed by the
> >>> performance metrics directorate.
> >>> http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-discard-rle-05
> >>>
> >>>   Draft is post-WGLC.
> >>>
> >>>   Many Thanks
> >>>    Shida
> >>>
> >>>
> >>
> >
> >
> 
> _______________________________________________
> pm-dir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pm-dir

---

From: Gonzalo Camarillo <[email-masked]>
Date: Wed, 3 Apr 2013 15:30:52 +0300

Thanks for the quick answer, Al!

Gonzalo

---

From: Alan Clark <[email-masked]>
Date: Wed, 03 Apr 2013 08:35:02 -0400

Hi Al, Gonzalo

I will expedite the review

Alan

---

From: "MORTON JR., ALFRED C (AL)" <[email-masked]>
Date: Wed, 3 Apr 2013 08:36:17 -0400

Great, thanks Alan!

> Of Alan Clark
> Sent: Wednesday, April 03, 2013 8:35 AM
> To: MORTON JR., ALFRED C (AL); Gonzalo Camarillo; Benoit Claise
> rtcp-xr-decodability

---

From: Alan Clark <[email-masked]>
Date: Fri, 05 Apr 2013 15:10:13 -0400

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 however there is
considerable scope for improvement in the clarity of definition of how these
metrics are used. 
 
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.²
 
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.
 
C.2  Sequence numbers
 
begin_seq and end_seq
 
These definitions simply say ³As defined inŠ² 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.
 
SoŠ..
 
³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²
 
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 Š..
 
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].
 
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.
 
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

---

From: Qin Wu <[email-masked]>
Date: Sun, 7 Apr 2013 16:36:29 +0800

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" <[email-masked]>
To: "Gonzalo Camarillo" <[email-masked]>; <[email-masked]>; "Benoit Claise" <[email-masked]>; "Dan (Dan)" <[email-masked]>; "Shida Schubert" <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; <[email-masked]>; "Al Morton" <[email-masked]>
Sent: Saturday, April 06, 2013 3:10 AM
Subject: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability

Alan Clark

A. General Comments
 
this draft redefines the metrics in RFC6390 template form 

[Qin]: Exactly.

however there is

[Qin]: Agree.
 
B. Applicability Section
 
1.4 Applicability
 
Suggest 

[Qin]: Okay. Your proposed text have been incorporated in (-v11).
 
C. Metrics Definitions
 
C.1 General

[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

[Qin]: Fixed in (-v11).
 
C.3 Metrics definitions
 
For example
 
Existing language S..

 

 

[Qin]: Fixed in (-v11).
 
C.4 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

C.5 PCR_error_count

 [Qin]: Good catch and have fixed in (-v11).

---

From: Benoit Claise <[email-masked]>
Date: Wed, 10 Apr 2013 15:52:51 +0200

Hi Qin,

And don't forget the RFC 6390 template usage.

Regards, Benoit

---

From: Qin Wu <[email-masked]>
Date: Thu, 11 Apr 2013 02:14:00 +0000

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:[email-masked]] 
发送时间: 2013年4月10日 21:53
收件人: Qin Wu
抄送: Alan Clark; Gonzalo Camarillo; [email-masked]; Dan (Dan); Shida Schubert; Huangyihong (Rachel); [email-masked]; [email-masked]; Al Morton
主题: Re: RFC6390 review of draft-ietf-xrblock-rtcp-xr-decodability

Hi Qin,

Regards, Benoit