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

[Alissa Cooper <[e-mail]>]

On 6/5/14, 4:03 AM, "Romascanu, Dan (Dan)" <[e-mail]> wrote:

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

Fair enough. I had not interpreted that original section 3 text to cover
these scrambling conditions.
Alissa

>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