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

From: Colin Perkins <[email-masked]>
Date: Mon, 10 Feb 2014 23:49:09 +0000

On 16 Dec 2013, at 18:10, [email-masked] 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 decodability 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).

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

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Tue, 11 Feb 2014 12:09:45 +0000

Hi Colin,

Please see inline.

Best regards,
Rachel

> -----Original Message-----
> From: xrblock [mailto:[email-masked]] 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
> 
> > 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
> 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?

> --
> Colin Perkins
> http://csperkins.org/
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: Colin Perkins <[email-masked]>
Date: Tue, 11 Feb 2014 22:23:39 +0000

Rachel,

On 11 Feb 2014, at 12:09, Huangyihong (Rachel) <[email-masked]> wrote:
…
>>> This draft is a work item of the Metric Blocks for use with RTCP’s Extended Report Framework Working Group of the IETF.
>>> 
>>>  that allows the reporting of MPEG2 TS decidability statistics metrics

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/

---

From: "Huangyihong (Rachel)" <[email-masked]>
Date: Wed, 12 Feb 2014 01:54:29 +0000

Hi Colin,

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

Best regards,
Rachel

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Wednesday, February 12, 2014 6:24 AM
> To: Huangyihong (Rachel)
> Cc: xrblock mailing list
> ...
> > 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?
> 
> 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/
> 
>