Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05

[Kevin Gross <[e-mail]>]

I'm not suggesting a change to how SCS is measured. We would continue to
use a 1 second measurement window. I'm proposing a change to the units for
threshold (to allow a wider range) and the units used for reporting (to
allow greater precision).

Using RTP timestamp units does require more care in sizing fields due to
the different RTP clock rates used for different types of streams. The most
demanding case I am aware of is RFC 3497 which uses a 148.5 MHz RTP clock.
16-bits is definitely not enough at this rate and 32-bits can even be
insufficient to the extent that RFC 3497 breaks some basic RTP stuff and
perhaps should be considered an outlier.

On the other hand, although there's a lot of precedent, I believe we need
to be working away from time representations limited to 1 ms resolution. I
don't often see a valid justification for arbitrarily limiting resolution
and there are emerging cases where the additional precision is significant
and useful. I still intend to write an I-D with timestamping
recommendations but need to get my existing drafts (clksrc, leap-second)
through the system before I can take this on. In the meantime, I will
continue to bring this up in draft comments.

Kevin Gross
[phone]
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org


On Mon, Jul 1, 2013 at 8:22 PM, Qin Wu <[e-mail]> wrote:

>  Hi, Kevin:****
>
> ** **
>
> I have two difficulties to change measurement unit.****
>
> draft-ietf-xrblock-rtcp-xr-loss-conceal-05 defines two XR metrics
> blocks,one is loss concealment block, the other is concealment seconds
> block.****
>
> I think changing unit from milliseconds (ms) to RTP timestamp unit is more
> applicable to Loss Concealment Block than concealment seconds Block.****
>
> ** **
>
> In the concealment seconds block, you are right, SCS threshold is better
> represented as a fraction 0/255 to 255/255,e.g., 5% of 1 seconds is 50ms.*
> ***
>
> However concealment seconds block is based on successive one second
> intervals as declared by a local clock and used to report the number of
> xxx seconds that occur. See 2nd paragraph of section 4, it said:****
>
> “****
>
>    The following metrics are based on successive one second intervals as**
> **
>
>    declared by a local clock.  This local clock does NOT need to be****
>
>    synchronized to any external time reference.  The starting time of****
>
>    this clock is unspecified.  Note that this implies that the same loss**
> **
>
>    pattern could result in slightly different count values, depending on**
> **
>
>    where the losses occur relative to the particular one-second****
>
>    demarcation points.  For example, two loss events occurring 50ms****
>
>    apart could result in either one concealed second or two, depending****
>
>    on the particular 1000 ms boundaries used.****
>
> ** **
>
> ”****
>
> So are you suggesting concealment seconds not following 1 seond intervals
> decleared by the local clock?****
>
> ** **
>
> In the loss concealment blocks, “Mean Playout Interrupt Size” is defined
> as 16bit field and uses “ms” as unit however****
>
> “On-time Playout Duration”,” Loss Concealment Duration”,” Buffer
> Adjustment Concealment Duration” are all defined ****
>
> As 32bit fields and also use “ms” as unit. So if we change 32 bit fields
> unit from “ms” into RTP timestamp unit,****
>
> How about 16 bit “Mean Playout Interrupt Size” field?****
>
> ** **
>
> Regards!****
>
> -Qin****
>
> ** **
>
> *From:* Kevin Gross [mailto:[e-mail]]
> *Sent:* Sunday, June 30, 2013 11:24 PM
> *To:* Qin Wu
> *Cc:* Colin Perkins; xrblock-chairs; xrblock
>
> *Subject:* Re: [xrblock] WGLC for
> draft-ietf-xrblock-rtcp-xr-loss-conceal-05****
>
>  ** **
>
> I doesn't quite make sense to me.****
>
> ** **
>
> It seems like reporting in RTP timestamp units would make things better
> for both the reporter and reportee. The reporter won't need to maintain a
> separate higher-precision counter and then do a conversion for reporting.
> (Or not implement a higher-precision counter and under report in the
> presence of frequent short events.) The reportee receives higher-precision
> reports.****
>
> ** **
>
> SCS threshold might be better represented as a fraction 0/255 to 255/255.
> This resolves your mixed-units concern and allows a wider range of SCS
> behavior.****
>
>
> ****
>
> Kevin Gross****
>
> [phone]****
>
> Media Network Consultant****
>
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org****
>
> ** **
>
> On Wed, Jun 19, 2013 at 6:35 PM, Qin Wu <[e-mail]> wrote:****
>
> Thanks!****
>
>
> -----Original Message-----
> From: Colin Perkins [mailto:[e-mail]]****
>
> Sent: Thursday, June 20, 2013 1:20 AM
> To: Qin Wu
> Cc: Shida Schubert; xrblock-chairs; xrblock
> Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-loss-conceal-05
>
> Qin,
>
> Makes sense, thanks.
>
> Colin
>
>
>
> On 18 Jun 2013, at 04:20, Qin Wu wrote:
> > Good points. I fully agree.
> > However changing measurement unit from RTP timestamp unit to ms may
> cause measurement unit inconsistency.
> >
> > Taking loss concealment metrics block as an example, both 32 bit On-time
> Playout Duration field and 16 bit Mean Playout Interrupt Size uses the same
> measurement unit (ms), if we only change measurement unit for all 32 bit
> fields that carry loss concealment metrics to RTP timestamp unit, this cause
> > Some fields in the block use "ms" as unit, some field uses RTP timestamp
> unit.
> >
> > Taking concealment seconds metrics as another example, "SCS Threshold"
> field also uses milliseconds as unit.
> >
> > Let me know what you think of this?
> >
> > Regards!
> > -Qin
> > -----Original Message-----
> > From: Colin Perkins [mailto:[e-mail]]
> > Sent: Tuesday, June 18, 2013 6:10 AM
> > To: Qin Wu
> > Cc: Shida Schubert; xrblock-chairs; xrblock
> > Subject: Re: [xrblock] WGLC for
> draft-ietf-xrblock-rtcp-xr-loss-conceal-05
> >
> > Qin,
> >
> > The length of time represented by an audio payload tends to be an
> integer number of milliseconds for frame-based codecs, but can have an
> arbitrary length for sample-based codecs. Using RTP timestamp units might
> allow you to precisely match up the timings, if that matters. Plus, don't
> you have RTP timestamp units, but would need to convert to milliseconds?
> >
> > Colin
> >
> >
> >
> > On 13 Jun 2013, at 06:34, Qin Wu wrote:
> >> Colin,
> >> Yes, you are right.
> >> The length of time represented by audio playload in the RTP packet is
> usually measured using ms.
> >> Another rationale is concealment metrics are just terminal related end
> system metrics and its calculation does not need to rely on RTP timestamp
> in the RTP packet.
> >>
> >> Regards!
> >> -Qin
> >> -----Original Message-----
> >> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Colin Perkins
> >> Sent: Wednesday, June 12, 2013 12:02 AM
> >> To: Shida Schubert
> >> Cc: xrblock-chairs; xrblock
> >> Subject: Re: [xrblock] WGLC for
> draft-ietf-xrblock-rtcp-xr-loss-conceal-05
> >>
> >> Shida,
> >>
> >> I've read the draft, and believe it's in reasonable shape to progress.
> I would be interested in hearing the authors' rationale for choosing ms as
> the measurement unit rather than RTP timestamp units, however. It would
> seem that there might be an argument for using RTP timestamp units, so the
> reports can exactly line-up with the audio data in the RTP packets.
> >>
> >> Colin
> >>
> >>
> >>
> >> On 29 May 2013, at 17:53, Shida Schubert wrote:
> >>> This is an announcement of a 2 weeks XRBLOCK WG last call on
> >>> "Report Block for Concealment metrics Reporting on Audio Applications"
> >>> prior to requesting publication of the document as a proposed standard.
> >>>
> >>> As per discussion at the last meeting, we are running a second
> >>> WGLC on this draft.
> >>>
> >>> Please send your comments, including nits, to the list by the
> >>>
> >>> 12th of June
> >>>
> >>> If you read the draft and you see no issues, concerns, or nits, please
> >>> express the fact that you have no issue progressing the draft on the
> >>> list as well.
> >>>
> >>> The latest version can be found here:
> >>>
> >>> http://tools.ietf.org/html/draft-ietf-xrblock-rtcp-xr-loss-conceal-05
> >>>
> >>> Regards
> >>>
> >>> Shida as co-chair
> >>> _______________________________________________
> >>> xrblock mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/xrblock
> >>
> >>
> >>
> >> --
> >> Colin Perkins
> >> http://csperkins.org/
>
> _______________________________________________
> xrblock mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/xrblock****
>
> ** **
>