Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

From: Glen Zorn <[email-masked]>
Date: Fri, 14 Dec 2012 17:04:01 +0700

I have reviewed this draft and have some comments.

*Section 1.1*
"SSRC" should be expanded on first usage.

*Section 1.4*
I'm pretty sure that jitter cannot be "encountered", because it is a 
timing abberation, not a physical object.  Suggest using "introduced" 
instead.

The second sentence says:

    These metrics are used to measure how the jitter buffer behave as a 
result of the
    jitter and applicable to a range of RTP applications.

The English language usage needs to be cleaned up a bit, but more 
importantly the statement sees to contradict the first sentence of 
Section 3 which says

    This block describes the configuration and operating parameters of
    the jitter buffer in the receiver of the RTP end system or RTP mixer
    which sends the report.

How can both be correct?

Sorry, but I have no idea what the third sentence means.

*Section 3*
It would be a very good idea, I think, to make capitalization and 
terminology consistent throughout the document.  An example from this 
section: "Instances of this Metrics Block" in sentence one but "this 
metric block" elsewhere.

Sentence two says "Instances of this Metrics Block refer by SSRC to the 
separate auxiliary Measurement Information block  [RFC6776] which 
contains measurement intervals." but AFAICT the Measurement Information 
lock describes only one interval.  Suggest changing to "Instances of 
this metric block refer by SSRC to the separate auxiliary Measurement 
Information block [RFC6776] which describes the measurement interval in 
use."

*Section 3.2*
The description of the "jitter buffer nominal delay" says that "It is 
calculated based on the time for packets spent in the jitter buffer."  
How is it calculated?

*Section 8*
s/Hideaki Yamada,Claire Bi,Colin Perkin/Hideaki Yamada, Claire Bi, Colin 
Perkins, Glen Zorn

:-)

---

From: Qin Wu <[email-masked]>
Date: Fri, 14 Dec 2012 19:20:00 +0800

----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "xrblock" <[email-masked]>
Sent: Friday, December 14, 2012 6:04 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

> "SSRC" should be expanded on first usage.

[Qin]: Okay.

> timing abberation, not a physical object.  Suggest using "introduced" 

[Qin]: Accepted.
> The English language usage needs to be cleaned up a bit, 

[Qin]: Okay, maybe we can say:
"
These metrics are used to measure how the jitter buffer behaves according to a result of the

Packet Delay Variation and can be applicable to a range of RTP applications. 
"
>but more 

[Qin]: I don't see they contradict. The configuration parameters are referred to 
Jitter Buffer Configuration set in the block header while
the operating parameters are referred to those metrics included 
in the payload of the block.

> Sorry, but I have no idea what the third sentence means.

[Qin]:What the third sentence means is
usually we don't consider how the terminal affect 
real-time application quality. however in pratice user may have different experience

to the application quality when they choose different terminal to playout the received RTP stream,e.g., ipad,PC,smartphone with

difference screen size, resolution and different buffer size to process the data.

So maybe we should rephase the paragraph in the section 4 as follows:

"

Real-time applications employ a jitter buffer to smooth out jitter

   introduced on the path from source to destination.  These metrics

   are used to measure how the jitter buffer at the receiving end of RTP stream behaves according to a result of the

   Packet Delay Variation in the network and applicable to a range of RTP applications.  

 These metrics reflect how terminal related factor affects real-time

   application quality and useful to provide more accurate end user quality experience.

"
> section: "Instances of this Metrics Block" in sentence one but "this 

[Qin]: Good point. We will check to fix that.

> Information block [RFC6776] which describes the measurement interval in 

[Qin]: Okay.

> calculated based on the time for packets spent in the jitter buffer."  

[Qin]:It will be calculate based on the difference between the time when the packet enter into the jitter buffer 
and the time when the packet come out from jitter buffer. It is mostly up to specific
implementation and doesn't need to spell out.

> s/Hideaki Yamada,Claire Bi,Colin Perkin/Hideaki Yamada, Claire Bi, Colin 

[Qin]: Okay, no problem. Thanks.
> :-)
> 
> 
> 
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock

---

From: Glen Zorn <[email-masked]>
Date: Sat, 15 Dec 2012 12:55:43 +0700

On 12/14/2012 06:20 PM, Qin Wu wrote:

...
 >> result of the jitter and applicable to a range of RTP
 >> applications.
 >>
 > [Qin]: Okay, maybe we can say: "
 >
 > Packet Delay Variation and can be applicable to a range of RTP
 > applications. "
 >> but more importantly the statement sees to contradict the first
 >> sentence of Section 3 which says
 >>
 >> the jitter buffer in the receiver of the RTP end system or RTP
 >> mixer which sends the report.
 >>
 >> How can both be correct?
 > [Qin]: I don't see they contradict. The configuration parameters are
 > referred to Jitter Buffer Configuration set in the block header while
 > the operating parameters are referred to those metrics included in
 > the payload of the block.

OK, I see; that was not at all obvious to me from the current text

 > [Qin]:What the third sentence means is usually we don't consider how
 > the terminal affect
 >
 > real-timeapplication quality. however in pratice user may have
 > different experience
 >
 > to the application quality when they choose different terminal to
 > playout the received RTP stream,e.g., ipad,PC,smartphone with
 >
 > are used to measure how the jitter buffer at the receiving end of
 > RTP stream behaves according to a result of the
 >

I have a different suggestion, now that I understand what you're trying 
to say :-).  How about this:

Real-time applications employ a jitter buffer to smooth out jitter 
introduced on the path from source to destination.  These metrics are 
used to report how the jitter buffer at the receiving end of RTP stream 
behaves as a result of jitter in the network and are applicable to a 
range of RTP applications.

These metrics reflect how terminal-related factors effect real-time 
application quality and are useful to provide better end-user quality of 
experience (QoE).

...

>
 >> *Section 3.2* The description of the "jitter buffer nominal delay"
 >> says that "It is calculated based on the time for packets spent in
 >> the jitter buffer." How is it calculated?
 > [Qin]:It will be calculate based on the difference between the time
 > when the packet enter into the jitter buffer and the time when the
 > packet come out from jitter buffer. It is mostly up to specific

So it's OK if two different implementations produce different numbers 
from the same data?  That doesn't seem very interoperable, somehow.  
Maybe one problem I'm having with this is that the way the word 
"nominal" is used doesn't map to any definition of which I'm aware.

...

---

From: Qin Wu <[email-masked]>
Date: Mon, 17 Dec 2012 10:04:24 +0800

----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Glen Zorn" <[email-masked]>; "xrblock" <[email-masked]>
Sent: Saturday, December 15, 2012 1:55 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

> application quality and are useful to provide better end-user quality of 

[Qin]: Your proposed change looks good, thanks.
> "nominal" is used doesn't map to any definition of which I'm aware.

[Qin]: Suppose a lot of packets are receieved in one measurement interval. Some packets arrive very earlier, some packets arrive very late.
some packets arrive extractly on time. Nominal packet are referred to the packet that arrives exactly on time
Since they have the same reference measurement point, usually they will get the same result.

For the definition, you also can see the metric "jitter buffer nominal delay  " defined in RFC3611,section4.7.7.

---

From: Glen Zorn <[email-masked]>
Date: Thu, 20 Dec 2012 14:24:44 +0700

On 12/17/2012 09:04 AM, Qin Wu wrote:
...

> Since they have the same reference measurement point, usually they will get the same result.

Usually?

> For the definition, you also can see the metric "jitter buffer nominal delay  " defined in RFC3611,section4.7.7.

Thanks for the reference, but it raises more questions than it answers 
for me.   The draft appears to duplicate most, but not all, of the 
fields related to jitter buffers included in the VoIP Metrics Report 
Block defined in RFC 3611, but says nothing about its relationship to 
that RFC (i.e., if it obsoletes or updates RFC 3611).  So as it stands 
it looks like if "jitter buffer absolute maximum delay" is to be 
reported the VoIP Metrics Report Block needs to be sent anyway.  I'm 
assuming that this is intentional but I don't recall any discussion of 
it on the list.  Was I just not paying attention?   Is there a plan to 
obsolete RFC 3611 at some point in the future (say, when all the XR 
blocks defined therein have been sliced & diced into the currently 
fashionable tiny hunks)?  It's not in the charter...

---

From: Qin Wu <[email-masked]>
Date: Thu, 20 Dec 2012 16:48:47 +0800

----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Glen Zorn" <[email-masked]>; "xrblock" <[email-masked]>
Sent: Thursday, December 20, 2012 3:24 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

>> Since they have the same reference measurement point, usually they will get the same result.

[Qin]: one update (-05) was done to clear this ambiguity based on recent comment 
from Kevin who has the similar concern as you. The change is
replace "It is calculated based on the time for packets spent in the jitter buffer." 
with "It is calculated based on the difference between the receipt time and the 
playout time for the packet that arrives exactly on time." 

With this justification text, you will see different implementations will not produce different numbers.

> fashionable tiny hunks)?  It's not in the charter...

[Qin]: The metric has been defined in RFC3611. However the block format to carry 
this metric need to be re-specified so that we can make such metric block can be
applicable to more other RTP applications rather than VOIP application since VOIP metric
report doesn't look reusable for video application. I don't think RFC3611 needs to be obseleted.

---

From: Glen Zorn <[email-masked]>
Date: Thu, 20 Dec 2012 17:20:55 +0700

> With this justification text, you will see different implementations will not produce different numbers.
Doesn't that depend upon what the application defines "exactly on time" 
to mean?

> report doesn't look reusable for video application. I don't think RFC3611 needs to be obseleted.

So this block is for use with any real-time application _except_ VOIP?'

---

From: Qin Wu <[email-masked]>
Date: Thu, 20 Dec 2012 18:49:09 +0800

----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "xrblock" <[email-masked]>
Sent: Thursday, December 20, 2012 6:20 PM
Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

> Doesn't that depend upon what the application defines "exactly on time" 

[Qin]: I think you can rely on the synchronization metadata at the RTP layer or TS layer (e.g., DTS/PTS ) to know whether the packet arrives on time.

> So this block is for use with any real-time application _except_ VOIP?'

[Qin]: Not necessary, it can apply to VOIP since the block is defined in the generic way.

---

From: Kevin Gross <[email-masked]>
Date: Thu, 20 Dec 2012 20:35:37 -0700

Good words from Glen. I suggest replacing "smooth out" with "absorb" below.

Kevin

On Fri, Dec 14, 2012 at 10:55 PM, Glen Zorn <[email-masked]> wrote:

>
> I have a different suggestion, now that I understand what you're trying to
> say :-).  How about this:
>
> introduced on the path from source to destination.  These metrics are used
> to report how the jitter buffer at the receiving end of RTP stream behaves
> as a result of jitter in the network and are applicable to a range of RTP
> applications.
>

---

From: Qin Wu <[email-masked]>
Date: Fri, 21 Dec 2012 17:09:47 +0800

Your suggested change looks good to me.

Regards!
-Qin
  ----- Original Message ----- 
  From: Kevin Gross 
  To: Glen Zorn 
  Cc: Qin Wu ; xrblock 
  Sent: Friday, December 21, 2012 11:35 AM
  Subject: Re: [xrblock] WGLC - draft-ietf-xrblock-rtcp-xr-jb-02.txt

  Kevin

    I have a different suggestion, now that I understand what you're trying to say :-).  How about this:

    Real-time applications employ a jitter buffer to smooth out jitter introduced on the path from source to destination.  These metrics are used to report how the jitter buffer at the receiving end of RTP stream behaves as a result of jitter in the network and are applicable to a range of RTP applications.

    These metrics reflect how terminal-related factors effect real-time application quality and are useful to provide better end-user quality of experience (QoE).