Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi-decodability-00.txt

[Colin Perkins <[e-mail]>]

Rachel,

On 11 Feb 2014, at 12:09, Huangyihong (Rachel) <[e-mail]> wrote:
…
>> -----Original Message-----
>> From: xrblock [mailto:[e-mail]] On Behalf Of Colin
>> Perkins
>> Sent: Tuesday, February 11, 2014 7:49 AM
>> To: xrblock mailing list
>> Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi-
>> decodability-00.txt
>> 
>> On 16 Dec 2013, at 18:10, [e-mail] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>> This draft is a work item of the Metric Blocks for use with RTCP’s Extended Report Framework Working Group of the IETF.
>>> 
>>> 	Title           : RTP Control Protocol (RTCP) Extended Report (XR) Block for MPEG2 Transport Stream (TS) Program Specific Information (PSI) Decodability Statistics Metrics reporting
>>> 	Author(s)       : Jiangang Tong
>>>                         Claire Bi
>>>                         Roni Even
>>>                         Qin Wu
>>>                         Rachel Huang
>>> 	Filename        : draft-ietf-xrblock-rtcp-xr-psi-decodability-00.txt
>>> 	Pages           : 10
>>> 	Date            : 2013-12-05
>>> 
>>> Abstract:
>>>  An MPEG2 Transport Stream (TS) is a standard container format used in
>>>  the transmission and storage of multimedia data.  Unicast/Multicast
>>>  MPEG2 TS over RTP is widely deployed in IPTV systems.  This document
>>>  defines an RTP Control Protocol (RTCP) Extended Report (XR) Block
>>>  that allows the reporting of MPEG2 TS decidability statistics metrics
>>>  related to transmissions of MPEG2 TS over RTP.  The metrics specified
>>>  in the RTCP XR Block are related to Program specific information
>>>  carried in MPEG TS.
>>> 
>>> 
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-xrblock-rtcp-xr-psi-decodability
>> 
>> It occurs to me that the issue with begin_seq and end_seq having to be
>> within the same RTP sequence number cycle to be unambiguous is present
>> in this draft, as well as the post-repair-loss-count draft (also in RFC
>> 6990 and maybe other places). The various *_count field here can
>> probably all be shortened to 16 bits without changing the utility of
>> the report block (several use 0xFFFF as an over-range value, so this
>> seems to be implied anyway).
> 
> The metrics in this draft count the errors of TS packets which is encapsulated in RTP packets. One RTP packets may contain 8 TS packets at most. Though it seldom happens, it is still possible that the value of the metrics over 16-bit. Right?

For some of the metrics, that might be true. I misread the draft. 

That said, many of the metrics in the draft are defined as counting the number of times something “does not come up at least every 0.5 seconds”. Given typical RTCP reporting intervals, it seems unlikely that these will come close to overflowing a 16 bit field, let alone a 32 bit field, in a single reporting interval. You might consider sizing the fields appropriately. 

Also, an undefined/over-range value of 0xffff makes sense for a 16 bit unsigned field, but not so much for a 32 bit field. These values should probably be adjusted to match the field sizes. 

-- 
Colin Perkins
http://csperkins.org/