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

Thanks, Alissa for the careful review. 

Maybe a short paragraph that explains the differences between implementations that support and do not support scrambling (flag values, relevant field) would be useful. 

It looks to me that - if the edits proposals are to be included - it would be good to update the I-D and let the WG a few days to read and comment before sending the I-D  to IETF LC. 

Regards,

Dan

> -----Original Message-----
> From: xrblock [mailto:xrblock-bounces@ietf.org] On Behalf Of Qin Wu
> Sent: Wednesday, June 04, 2014 7:33 AM
> To: Alissa Cooper; xrblock@ietf.org
> Subject: Re: [xrblock] AD evaluation: draft-ietf-xrblock-rtcp-xr-psi-
> decodability-03
> 
> 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:xrblock-bounces@ietf.org] 代表 Alissa Cooper
> 发送时间: 2014年6月4日 5:08
> 收件人: xrblock@ietf.org
> 主题: [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
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock
> _______________________________________________
> xrblock mailing list
> xrblock@ietf.org
> https://www.ietf.org/mailman/listinfo/xrblock