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

[Qin Wu <[e-mail]>]

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.
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_101
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 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.
"

(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].
"

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