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

[Qin Wu <[e-mail]>]

Hi,
Dan is right, we didn't consider scrambling. However some error may be counted due to scrambling being applied.
To make the text in section more clear, we propose the following change.
NEW TEXT:
"
   In these parameters, scrambling may be considered. The other parameters are ignored since they do not apply to all MPEG2
   implementations.  For further information on these parameters, see
   [ETSI].
"
I will issue a new version soon based on our discussion so far. 

Regards!
-Qin
-----邮件原件-----
发件人: xrblock [mailto:[e-mail]] 代表 Romascanu, Dan (Dan)
发送时间: 2014年6月5日 19:03
收件人: Alissa Cooper; Qin Wu; [e-mail]
主题: Re: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-psi-decodability-03

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
_______________________________________________
xrblock mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/xrblock