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

[Alissa Cooper <[e-mail]>]

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