Re: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-psi-decodability-03

["Romascanu, Dan (Dan)" <[e-mail]>]

Hi Alissa,

Thanks again for the attentive review. To address your comment - the shepherd review (maybe other) did look at the ETSI definitions. This document does not represent c complete rendering of the capabilities made available of that specification, but a most commonly implemented subset, which is indicated by the text in section 3: 

> The other parameters are ignored since they do not apply to all MPEG2
   implementations.  For further information on these parameters, see
   [ETSI].

This probably deserved being more detailed - in the case of scrambling, the error was to not consider scrambling, or at least to not make clear that it is left out. I personally am happy with the latest proposal suggested by Qin. 

Regards,

Dan


> -----Original Message-----
> From: xrblock [mailto:[e-mail]] On Behalf Of Alissa Cooper
> Sent: Thursday, June 05, 2014 5:42 AM
> To: Qin Wu; [e-mail]
> Subject: Re: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-psi-
> decodability-03
> 
> Hi Qin,
> 
> Thanks for your response. My comments are inline.
> 
> One note for the WG: I’m a little surprised that earlier reviews (e.g., during
> WGLC) did not catch some of these errors. For future documents of this sort,
> it might be good to make sure that at least one reviewer or the document
> shepherd does a comparison between what is specified in the I-D and what is
> specified in other corresponding specs.
> 
> On 6/3/14, 10:33 PM, "Qin Wu" <[e-mail]> wrote:
> 
> >Hi, Alissa:
> >Thanks for valuable comments. We think not all implementations support
> >scrambling and scrambling adds a lot of complexity for packet
> >processing since it needs to support encryption and decryption.
> >But you are right, to get consistent with ETSI TR 101 290, I am okay
> >with adding scrambling feature.
> 
> I didn’t mean to take a position on the scrambling. But since it was not
> addressed in the draft and references are made to the ETSI document, it
> needs to be explained one way or the other. If the scrambling-based
> conditions are not relevant, that should be explained; if they are part of the
> logic that yields the errors, that should be explained.
> 
> >For your comments, please see my reply below.
> >
> >Regards!
> >-Qin
> >-----邮件原件-----
> >发件人: xrblock [mailto:[e-mail]] 代表 Alissa Cooper
> >发送时间: 2014年6月4日 5:08
> >收件人: [e-mail]
> >主题: [xrblock] AD evaluation:
> >draft-ietf-xrblock-rtcp-xr-psi-decodability-03
> >
> >I have reviewed this draft in preparation for IETF LC and I have some
> >questions before proceeding with the LC announcement.
> >
> >In Section 3, there seem to be some inconsistencies between the way
> >that some of the fields are defined in the block and the way the
> >corresponding metrics are described in ETSI TR 101 290 (assuming
> >http://www.etsi.org/deliver/etsi_tr/101200_101299/101290/01.02.01_60/tr
> >_10
> >1
> >290v010201p.pdf is the correct reference for that document):
> >
> >(1) PAT_error_count is defined in the draft as:
> >
> >"A count of the number of PAT errors that occurred in the above
> >      sequence number interval.  The program association table (PAT) is
> >      the only packet with packet ID (PID) 0x 0000.  A PAT error occurs
> >      when it does not occur at least every 0.5s or the table has an ID
> >      other than 0x 00, as defined in section 5.2.1 of [ETSI].  Every
> >      program within the MPEG TS stream is listed in the PAT; if it is
> >      missing, then no programs can be decoded."
> >
> >Whereas in the ETSI document, a PAT_error is defined as:
> >
> >"PID 0x0000 does not occur at least every 0,5 s a PID 0x0000 does not
> >contain a table_id 0x00 ( i.e.
> >a PAT)
> >Scrambling_control_field is not 00 for PID 0x0000”
> >
> >Is the definition in the draft supposed to be equivalent to the first
> >two conditions in the ETSI definition? If so, that is not quite clear
> >from the draft. Why is the Scrambling_control_field condition not also
> >part of the definition in the draft?
> >
> >[Qin]: I propose the following change:
> >NEW TEXT:
> >"
> >   PAT_error_count: 16 bits
> >
> >      A count of the number of PAT errors that occurred in the above
> >      sequence number interval.  The program association table (PAT) is
> >      the only packet with packet ID (PID) 0x 0000.  A PAT error occurs
> >      when it does not occur at least every 0.5s or the table has an ID
> >      other than 0x00 or Scrambling_control_field in the TS packet header
> >       is not 00 for PID 0x0000, as defined in section 5.2.1 of [ETSI].
> >Every
> >      program within the MPEG TS stream is listed in the PAT; if it is
> >      missing, then no programs can be decoded.
> >"
> 
> I think this would be clearer if you break out the conditions:
> 
> PAT_error_count: 16 bits
> 
>       A count of the number of PAT errors that occurred in the above sequence
> number interval.  The program association table (PAT) is the only packet with
> packet ID (PID) 0x0000.  A PAT error occurs when: (1) a packet with PID
> 0x0000 does not occur at least every 0.5 seconds, or (2) a packet with PID
> 0x0000 does not contain a table_id 0x00 (i.e., a PAT), or (3) the
> Scrambling_control_field in the TS packet header is not 00 for a packet with
> PID 0x0000. See section 5.2.1 of [ETSI]. Every program within the MPEG TS
> stream is listed in the PAT; if it is missing, then no programs can be decoded.
> 
> 
> I would suggest making similar changes to all of the field definitions that
> describe a list of multiple conditions that trigger the errors.
> 
> 
> 
> 
> 
> 
> 
> 
> >
> >I have the same questions about PAT_error_2_count.
> >
> >[Qin]:How about the following change:
> >NEW TEXT:
> >"
> >   PAT_error_2_count: 16 bits
> >
> >      A count of the number of PAT2 errors that occurred in the above
> >      sequence number interval.  A PAT2 error occurs when it does not
> >      occur at least every 0.5s or the table has an ID other than 0x00
> >      or there is more than one table ID 0x 00 inside the packet with
> >      the PAT PID or Scrambling_control_field in the TS packet header
> >      is not 00 for PID 0x0000, as defined in section 5.2.1 of [ETSI].
> >"
> >
> >(2) In the draft, PMT_error_count and PMT_error_2_count have the exact
> >same definition. But in the ETSI document, a PMT_error is different
> >from a PMT_error_2. Here are the definitions from the ETSI document:
> >
> >PMT_error:
> >"Sections with table_id 0x02, ( i. e. a PMT), do not occur at least
> >every
> >0,5 s on the PID which is referred to in the PAT
> >Scrambling_control_field is not 00 for all PIDs containing sections
> >with table_id 0x02 (i.e. a PMT)”
> >
> >PMT_error_2:
> >"Sections with table_id 0x02, (i.e. a PMT), do not occur at least every
> >0,5 s on each program_map_PID which is referred to in the PAT
> >Scrambling_control_field is not 00 for all packets containing
> >information of sections with table_id
> >0x02 (i.e. a PMT) on each program_map_PID which is referred to in the
> PAT"
> >
> >Are the equivalent definitions of PMT_error_count and
> PMT_error_2_count
> >in the draft intentional? If so, why define the same metric twice, and
> >why make PMT_error_2_count different from the way PMT_error_2 is
> >defined in the ETSI document?
> >
> >[Qin]: Good catch, without scrambling, definitions of PMT_error_count
> >and PMT_error_2_count in the draft are equivalent.
> >But in ETSI document, PMT_error_2_count is different from
> >PMT_error_count since the former excludes specifically network_PID.
> >I propose the following changes to definitions of PMT_error_count and
> >PMT_error_2_count in the draft:
> >NEW TEXT:
> >"
> >   PMT_error_count: 16 bits
> >
> >      A count of the number of PMT_errors that occurred in the above
> >      sequence number interval.  A PMT_error occurs when the program map
> >      table (PMT) does not come up at least every 0.5s on the PID that
> >      is referred to in the PAT or Scrambling_control_field in the TS
> >packet header is not 00 for all PIDs
> >      containing sections with table_id 0x02 (i.e. a PMT), as defined
> >in the section 5.2.1 of
> >      [ETSI].
> >
> >      The measured value is unsigned value.  If the measurement is
> >      unavailable, the value 0xFFFF MUST be reported.  Note that
> >      PMT_error_count and PMT_error_2_count MUST NOT be reported at
> the
> >      same time in the same metric block.  If PMT_error_count is
> >      reported, PMT_error_2_count MUST be set to 0xFFFF.
> >
> >   PMT_error_2_count: 16 bits
> >
> >      A count of the number of PMT2 errors that occurred in the above
> >      sequence number interval.  A PMT2_error occurs when the program
> >      map table (PMT) does not come up at least every 0.5s on the PID
> >      that is referred to in the PAT or Scrambling_control_field in the
> >TS packet header is not 00 for all packets
> >      containing information of sections with table_id
> >      0x02 (i.e. a PMT) on each program_map_PID
> >      which is referred to in the PAT, as defined in the section 5.2.1 of
> >      [ETSI].
> >
> >      The measured value is unsigned value.  If the measurement is
> >      unavailable, the value 0xFFFF MUST be reported.  Note that
> >      PMT_error_count and PMT_error_2_count MUST NOT be reported at
> the
> >      same time in the same metric block.  If PMT_error_2_count is
> >      reported, PMT_error_count MUST be set to 0xFFFF.
> >"
> 
> If you can list the conditions as I suggest above, I think these are okay.
> 
> >
> >(3) The draft defines PID_error_count as:
> >
> >"A count of the number of PID_errors that occurred in the above
> >      sequence number interval.  A PID_error occurs when MPEG TS streams
> >      are remultiplexed and any PID doesn't refer to an actual data
> >      stream, as defined in the section 5.2.2 of [ETSI]."
> >
> >
> >PID_error is defined in 5.2.1 of the ETSI draft, not 5.2.2. Is the
> >definition in 5.2.1 what this field in the block is supposed to
> >correspond to, or is it something else?
> >
> >[Qin]:Good catch, it should be 5.2.1.
> >
> >(4) CAT_error_count is defined in the draft as:
> >
> >"A count of the number of CAT_errors that occurred in the above
> >      sequence number interval.  A CAT_error occurs when the table has
> >      an ID other than 0x 01,as defined in the section 5.2.2 of [ETSI].”
> >
> >CAT_error is defined in the ETSI document as:
> >
> >"Packets with transport_scrambling_control not 00 present, but no
> >section with table_id = 0x01 (i.e. a
> >CAT) present
> >Section with table_id other than 0x01
> >(i.e. not a CAT) found on PID 0x0001"
> >
> >[Qin]: How about the following change:
> >NEW TEXT:
> >"
> >   CAT_error_count: 16 bits
> >
> >      A count of the number of CAT_errors that occurred in the above
> >      sequence number interval.  A CAT_error occurs when the table has
> >      an ID other than 0x 01 or section with table_id = 0x01 (i.e. a
> >      CAT)is not present when scrambling is employed,as defined in the
> >section 5.2.2 of [ETSI].
> >"
> 
> In re-reading this, I’m actually not sure I understand the first condition in the
> ETSI document and how it maps onto the error count being defined here.
> Does a CAT_error occur when *any* packet has
> transport_scrambling_control != 00 and no section with table_id==0x01? Is
> CAT_error_count supposed to reflect the number of such packets that occur
> within the (begin_seq, end_seq) interval?
> 
> Thanks,
> Alissa
> 
> 
> >
> >Again I’m curious why the definition in the draft seems to have only
> >one portion of one of the conditions that appear in the ETSI document.
> >
> >[Qin]: Addressed with the above proposed changes. Thanks.
> >
> >Thanks,
> >Alissa
> >
> >
> >_______________________________________________
> >xrblock mailing list
> >[e-mail]
> >https://www.ietf.org/mailman/listinfo/xrblock
> 
> 
> _______________________________________________
> xrblock mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock