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

["Huangyihong (Rachel)" <[e-mail]>]

Hi Colin,

I get your point. It will be fixed according to your comments. Thanks. 

Best regards,
Rachel

> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]
> Sent: Wednesday, February 12, 2014 6:24 AM
> To: Huangyihong (Rachel)
> Cc: xrblock mailing list
> Subject: Re: [xrblock] I-D Action: draft-ietf-xrblock-rtcp-xr-psi-
> decodability-00.txt
> 
> 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/
> 
>