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

[Qin Wu <[e-mail]>]

Hi,Dan:
Do we really need to distinguish implementation that support scrambling from implementation that don't?
For implementation that don't support scrambling, the error count due to employing scrambling in each related metric can be set to zero.
Take PAT_error_count as an example,
A PAT error occurs when it meets any one of the following three conditions
1. when PAT does not occur at least every 0.5s
2.the table has an ID other than 0x00 
3. Scrambling_control_field in the TS packet header
  is not 00 for PID 0x0000, as defined in section 5.2.1 of [ETSI].

The error count is sum of error count due to either condition listed above. The error count due to the 3rd condition can be set to zero 
when implementation doesn't support scrambling.
Whether scrambling is supported or not, Scrambling_control_field needs to be present in the TS packet and set an appropriate value.

So I think using a new flag bit to make distinction is not necessary since each scrambling related metric only conside scrambling related condition as one of possible condition.
For implementation that don't support scrambling, there is no error being counted due to scrambling being applied.

I will update the draft if you agree with the proposed changes.

Regards!
-Qin
-----邮件原件-----
发件人: Romascanu, Dan (Dan) [mailto:[e-mail]] 
发送时间: 2014年6月4日 18:08
收件人: Qin Wu; Alissa Cooper; [e-mail]
主题: 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:[e-mail]] On Behalf Of Qin Wu
> Sent: Wednesday, June 04, 2014 7:33 AM
> To: Alissa Cooper; [e-mail]
> 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:[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/t
> r_
> 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
> _______________________________________________
> xrblock mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock