Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

From: Kevin Gross <[email-masked]>
Date: Wed, 1 Feb 2012 09:08:43 -0700

The 15 microsecond (1/2^16) resolution you cite is almost two orders of
magnitude better than the millisecond resolution reported here. Measurement
accuracy may improve in the future and, if so, by changing now, we will
avoid having to revise in the future. What's the downside to improving this?

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org

On Mon, Jan 30, 2012 at 12:51 AM, Qin Wu <[email-masked]> wrote:

> **
> Hi, Kevin:
> The round trip delay metric defined in the
> draft-ietf-xrblock-rtcp-xr-delay is determined using RTCP SR/RR in RFC3550.
> according to the following formula:
> round-trip delay = (A - LSR - DLSR)
> or using RTCP RRTR/DLRR in RFC3611 according to the following formula:
> round -trip delay=(A-LRR-DLRR)
>
> The measurement method for round trip delay is defined in the section
> 6.4.1 or figure 2 of RFC3550.
>
> With the current measurement method defined in the RFC3550, microsecond
> precision requirement is hard to be satisifed, since
> the measurement precision of the delay metric is limited to far less than
> the Minimum precision of LSR or DLSR in the above formula. The LSR and
> DLSR precision
> is 1/2^16 second that is greater than 1 microsecond.
>
> Hope this clarifies.
>
>
> Regards!
> -Qin
> ----- Original Message -----
>
> *From:* Kevin Gross <[email-masked]>
> *To:* xrblock <[email-masked]>
> *Sent:* Monday, January 30, 2012 8:19 AM
> *Subject:* Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-delay
> (Ending on Feb 3)
>
> I would like to suggest that milliseconds are too crude a measurement for
> modern IP networks. IP forwarding is accomplished in a small number of
> microseconds by current hardware. Many applications operate locally and are
> not significantly burdened by the speed of light. Live media and financial
> processing applications do take advantage of this performance and would
> benefit from improved resolution in these metrics. I would suggest
> microsecond precision would be minimally adequate.
>
> Kevin Gross
> +1-303-447-0517
> Media Network Consultant
> AVA Networks - www.AVAnw.com <http://www.avanw.com/>, www.X192.org
>
>
> On Sun, Jan 29, 2012 at 3:23 AM, Shida Schubert <[email-masked]> wrote:
>
>>
>> Folks;
>>
>>  The WGLC for this draft is ending in less than a week
>> and we have only received one feedback. I highly
>> encourage people to read the draft and provide comments
>> or if you have read the current version already and you found
>> no issue express it on the list.
>>
>>  Many Thanks
>>  Shida (As Co-Chair)
>>
>> On Jan 21, 2012, at 7:20 AM, Charles Eckel (eckelcu) wrote:
>>
>> > (As WG Co-Chair)
>> >
>> > This is an announcement of XRBLOCK WG last call on "RTCP XR Report Block
>> > for Delay metric Reporting" prior to requesting publication of the
>> > document as a proposed standard.
>> >
>> > This is a two week working group last call. Please send your comments,
>> > including nits, to the list by the 3rd of February.
>> >
>> > 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/wg/xrblock/draft-ietf-xrblock-rtcp-xr-delay/
>> >
>> > Cheers,
>> > Charles
>> > _______________________________________________
>> > xrblock mailing list
>> > [email-masked]
>> > https://www.ietf.org/mailman/listinfo/xrblock
>>
>> _______________________________________________
>> xrblock mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/xrblock
>>
>
>  ------------------------------
>
> _______________________________________________
> xrblock mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xrblock
>
>

---

From: Qin Wu <[email-masked]>
Date: Fri, 03 Feb 2012 14:44:24 +0800

I am not discouraging such improvement. But I have the following concerns:
1. the order of milliseconds has been widely used to describe the delay requirements for the most of RTP applications.
 e.g., In the case of multimedia confercing, the end-to-end delay has to be at most a few hundred milliseconds;
In the case of voice transmissions  over a packet-switched network, toll quality can be obtained only when latency is less than 200 milliseconds (ms). Nevertheless, even
with a delay between 200 and 400 ms, a transmission is acceptable. But when the delay is greater than 400 ms, the audio connection is no longer acceptable.
2.The current measurement method using RTCP SR/SR in RFC3550 can not meet the microsecond resolution requirements since DLSR are in the oder of (1/2^16)seconds.
3.I am not aware any measurement method for calculating round trip delay better than that determined using RTCP SR/RR can achieve microsecond resolution requirements.

Fortunetely RFC2679 provides one measurement method for calcualting one way delay that can achieve microseconds resolution requirement. 
That's why we write one new XR Block draft (http://tools.ietf.org/html/draft-wu-xrblock-rtcp-xr-one-way-delay-00) and discuss how one way 
delay can satisfy microsecond resolution requirement. This draft is also motivated by the last IETF meeting discussion one draft-ietf-xrblock-rtcp-xr-delay presentation
and follow the consensus in the last meeting. The consenses  is to separate one way delay from draft-ietf-xrblock-rtcp-xr-delay.

Regards!
-Qin
  ----- Original Message ----- 
  From: Kevin Gross 
  To: xrblock 
  Sent: Thursday, February 02, 2012 12:08 AM
  Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

  The 15 microsecond (1/2^16) resolution you cite is almost two orders of magnitude better than the millisecond resolution reported here. Measurement accuracy may improve in the future and, if so, by changing now, we will avoid having to revise in the future. What's the downside to improving this?

  Kevin Gross

  +1-303-447-0517
  Media Network Consultant

  AVA Networks - www.AVAnw.com, www.X192.org

    Hi, Kevin:
    The round trip delay metric defined in the draft-ietf-xrblock-rtcp-xr-delay is determined using RTCP SR/RR in RFC3550.

    The measurement method for round trip delay is defined in the section 6.4.1 or figure 2 of RFC3550.

    With the current measurement method defined in the RFC3550, microsecond precision requirement is hard to be satisifed, since
    the measurement precision of the delay metric is limited to far less than the Minimum precision of LSR or DLSR in the above formula. The LSR and DLSR precision
    is 1/2^16 second that is greater than 1 microsecond.

    Hope this clarifies.

    Regards!
    -Qin
    ----- Original Message ----- 
      From: Kevin Gross 
      To: xrblock 
      Sent: Monday, January 30, 2012 8:19 AM
      Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

      I would like to suggest that milliseconds are too crude a measurement for modern IP networks. IP forwarding is accomplished in a small number of microseconds by current hardware. Many applications operate locally and are not significantly burdened by the speed of light. Live media and financial processing applications do take advantage of this performance and would benefit from improved resolution in these metrics. I would suggest microsecond precision would be minimally adequate. 

      Kevin Gross

      +1-303-447-0517
      Media Network Consultant

      AVA Networks - www.AVAnw.com, www.X192.org

        Folks;

         Many Thanks
         Shida (As Co-Chair)

--------------------------------------------------------------------------

------------------------------------------------------------------------------

---

From: Glen Zorn <[email-masked]>
Date: Fri, 03 Feb 2012 19:33:38 +0700

I have reviewed this draft and have just a few comments.

Section 1.4 says "These metrics are applicable to a range of RTP
applications."  An example or two might be nice here.

In Section 3.2:

s/sampled,Interval/sampled, Interval/

The use of capitalization should be consistent, i.e., either "sampled,
interval or cumulative metrics" and "sampled value" etc. or "Sampled,
Interval or Cumulative metrics" and "Sampled Value" etc.

"They SHOULD be set to zero by senders and MUST be ignored by
receivers."  I think this is backwards, instead it should read "They
MUST be set to zero by senders and SHOULD be ignored by receivers."

s%accumulation/encoding%accumulation/encoding%

s%decoding / playout%decoding/playout

In Section 7, did all those people actually make textual contributions
to this draft?  If not, this section should be pruned to include those
who did and a new "Acknowledgments" section added.

Aside from that, I think it's fine.

---

From: Qin Wu <[email-masked]>
Date: Fri, 03 Feb 2012 14:01:49 +0000

Hi, Kevin:
Just one more clarification in case I misunderstand your followup comment.
If you propose to use microsecond as measurement unit to replace millisecond we adopted currently,
I think my concerns mentioned below early should apply.
However if you propose to use 1/2^16 second as measurement unit to replace millisecond, I think this is a good idea and is just like what Colin proposed on this thread. I like to adopt this in the new version.

Regards!
-Qin
________________________________________
发件人: [email-masked] [[email-masked]] 代表 Qin Wu [[email-masked]]
发送时间: 2012年2月3日 14:44
到: Kevin Gross; xrblock
主题: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

Regards!
-Qin
----- Original Message -----
From: Kevin Gross<mailto:[email-masked]>
To: xrblock<mailto:[email-masked]>
Sent: Thursday, February 02, 2012 12:08 AM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

Kevin Gross
+1-303-447-0517
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>, www.X192.org<http://www.X192.org>

On Mon, Jan 30, 2012 at 12:51 AM, Qin Wu <[email-masked]<mailto:[email-masked]>> wrote:
Hi, Kevin:

Hope this clarifies.

Regards!
-Qin
----- Original Message -----
From: Kevin Gross<mailto:[email-masked]>
To: xrblock<mailto:[email-masked]>
Sent: Monday, January 30, 2012 8:19 AM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

Kevin Gross
+1-303-447-0517<tel:%2B1-303-447-0517>
Media Network Consultant
AVA Networks - www.AVAnw.com<http://www.avanw.com/>, www.X192.org<http://www.X192.org>

On Sun, Jan 29, 2012 at 3:23 AM, Shida Schubert <[email-masked]<mailto:[email-masked]>> wrote:

Folks;

 Many Thanks
 Shida (As Co-Chair)

On Jan 21, 2012, at 7:20 AM, Charles Eckel (eckelcu) wrote:

> [email-masked]<mailto:[email-masked]>

_______________________________________________
xrblock mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/xrblock

________________________________

_______________________________________________
xrblock mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/xrblock

________________________________

---

From: Kevin Gross <[email-masked]>
Date: Fri, 3 Feb 2012 15:29:08 -0700

A 16-bit metric in 1/2^16 units tops out at 1 second. When things are
crippled (e.g. Bufferbloat), latency can exceed 1 second.

Accuracy for my applications are on the order of an Ethernet packet time. I
suggested 1 microsecond because I wanted to offer a solution not just a
problem, because it meets the requirement and because it is inline with
current proposal, just more accurate.

I don't see a post from Colin on this thread. Perhaps you're thinking of
another discussion.

I'll need a little time to study the timers in SR/RR before responding
further.

Kevin Gross
+1-303-447-0517
Media Network Consultant

2012/2/3 Qin Wu <[email-masked]>

> However if you propose to use 1/2^16 second as measurement unit to replace
> millisecond, I think this is a good idea and is just like what Colin
> proposed on this thread. I like to adopt this in the new version.
>
> Regards!
> -Qin
> 1. the order of milliseconds has been widely used to describe the delay
> requirements for the most of RTP applications.
> In the case of voice transmissions  over a packet-switched network, toll
> quality can be obtained only when latency is less than 200 milliseconds
> (ms). Nevertheless, even
> with a delay between 200 and 400 ms, a transmission is acceptable. But
> when the delay is greater than 400 ms, the audio connection is no longer
> acceptable.
> 2.The current measurement method using RTCP SR/SR in RFC3550 can not meet
> the microsecond resolution requirements since DLSR are in the oder of
> (1/2^16)seconds.
> 3.I am not aware any measurement method for calculating round trip delay
> better than that determined using RTCP SR/RR can achieve microsecond
> resolution requirements.
>
> Fortunetely RFC2679 provides one measurement method for calcualting one
> way delay that can achieve microseconds resolution requirement.
> That's why we write one new XR Block draft (
> http://tools.ietf.org/html/draft-wu-xrblock-rtcp-xr-one-way-delay-00) and
> discuss how one way
> delay can satisfy microsecond resolution requirement. This draft is also
> motivated by the last IETF meeting discussion one
> draft-ietf-xrblock-rtcp-xr-delay presentation
> and follow the consensus in the last meeting. The consenses  is to
> separate one way delay from draft-ietf-xrblock-rtcp-xr-delay.
>
> Regards!
> -Qin
> the Minimum precision of LSR or DLSR in the above formula. The LSR and DLSR
> precision

---

From: Qin Wu <[email-masked]>
Date: Mon, 06 Feb 2012 10:46:10 +0800

----- Original Message ----- 
  From: Kevin Gross 
  To: xrblock 
  Sent: Saturday, February 04, 2012 6:29 AM
  Subject: Re: [xrblock]答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

  A 16-bit metric in 1/2^16 units tops out at 1 second. When things are crippled (e.g. Bufferbloat), latency can exceed 1 second.
[Qin]: Latency exceeding 1 second MUST be not acceptable for any real time application. 
So the question is do we really need to report unacceptable latency that is more than 1 second? If the answer is yes, we can easily fix this 
issue by allocating 8 more bits for each 16bit metric. Any opinion?

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Mon, 6 Feb 2012 05:50:39 +0100

Hello Qin:
1st What's your definition of "realtime"?
2nd Why is more than one second not acceptable, or more exactly: did you consider the plethora of possible application protocols (and services) over RTP? Even for conversational services ...

Regards,
Albrecht

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Montag, 6. Februar 2012 03:46
To: Kevin Gross; xrblock
Subject: Re: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

---

From: Qin Wu <[email-masked]>
Date: Mon, 06 Feb 2012 14:19:49 +0800

Hi,Albrecht:
Thank for sharing your view. please see my replies below.
----- Original Message ----- 
  From: Schwarz, Albrecht (Albrecht) 
  To: Qin Wu ; Kevin Gross ; xrblock 
  Sent: Monday, February 06, 2012 12:50 PM
  Subject: RE: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

  Hello Qin:
  1st What's your definition of "realtime"?
[Qin]: This is a difficult question. Do you have answer?
  2nd Why is more than one second not acceptable, or more exactly: did you consider the plethora of possible application protocols (and services) over RTP? Even for conversational services ...
[Qin]: I don't have a clear answer to what the range of unacceptable delay for real time application is. but when I read RFC4588, section 1, 2nd paragraph:
"
In the case of multimedia conferencing, the end-to-end delay has to
be at most a few hundred milliseconds in order to guarantee
interactivity
"
This told me that multimedia confercing has end to end delay in the order of a few hundred milliseconds.
Also I am ware of that in ITU-T G.114, it is recommended that for VOIP application, a steady-state end-to-end delay of 150 ms as the upper
limit and rates 400 ms as generally unacceptable delay.
That's why I assume the delay more than 1 second(i.e.,1000 milliseconds) is unacceptable. If I am wrong, please correct me.
  Regards,
  Albrecht

----------------------------------------------------------------------------
    From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
    Sent: Montag, 6. Februar 2012 03:46
    To: Kevin Gross; xrblock
    Subject: Re: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Mon, 6 Feb 2012 09:02:25 +0100

The considered GoS metric is end-to-end transfer delay (oneway).
You are appearently focusing on the category of CONVERSATIONAL services (like telephony, conferencing, telepresence, etc).
However, looking at STREAMING services, you may find use cases where even multiples of seconds would be acceptable (particularily if unidirectional).

Don't pick again a low latency example ...:-)

________________________________
From: Qin Wu [mailto:[email-masked]]
Sent: Montag, 6. Februar 2012 07:20
To: Schwarz, Albrecht (Albrecht); Kevin Gross; xrblock
Subject: Re: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

Hi,Albrecht:
----- Original Message -----
From: Schwarz, Albrecht (Albrecht)<mailto:[email-masked]>
To: Qin Wu<mailto:[email-masked]> ; Kevin Gross<mailto:[email-masked]> ; xrblock<mailto:[email-masked]>
Sent: Monday, February 06, 2012 12:50 PM
Subject: RE: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

Hello Qin:

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Qin Wu
Sent: Montag, 6. Februar 2012 03:46
To: Kevin Gross; xrblock
Subject: Re: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

---

From: Qin Wu <[email-masked]>
Date: Mon, 06 Feb 2012 16:13:37 +0800

Hi, Albrecht:
I agree the examples I gave are all low latency examples.
Would you like to point me a reference or specification 
that says multiple seconds end to end delay for streaming
service(e.g., IPTV service, VOD service) are allowed?
This will help us to understand what the acceptable end 
to end delay is for any streaming service and see how 
many extra bits are required to report such metric in the 
order of 1/65536 sec.

Regards!
-Qin
  ----- Original Message ----- 
  From: Schwarz, Albrecht (Albrecht) 
  To: Qin Wu ; Kevin Gross ; xrblock 
  Sent: Monday, February 06, 2012 4:02 PM
  Subject: RE: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

    Hi,Albrecht:
    ----- Original Message ----- 
      From: Schwarz, Albrecht (Albrecht) 
      To: Qin Wu ; Kevin Gross ; xrblock 
      Sent: Monday, February 06, 2012 12:50 PM
      Subject: RE: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

      Hello Qin:

------------------------------------------------------------------------
        From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
        Sent: Montag, 6. Februar 2012 03:46
        To: Kevin Gross; xrblock
        Subject: Re: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

        ----- Original Message ----- 
          From: Kevin Gross 
          To: xrblock

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Mon, 6 Feb 2012 09:36:18 +0100

Hello Qin,
instead of refering a particular service specification, I think that the justification is much simpler, just from MEASUREMENTS (similar as TEST) perspective:
The value range (and resolution) for MEASUREMENTS should be (at least one order) "better" than the communication SERVICE specification(s) with regards to considered performance metrics.
An architectural criteria from good protocol design perspective. May be reflected in the draft.
Hence, a value range greater than one second should be covered.

BR,
Albrecht

Sent: Montag, 6. Februar 2012 09:14

Hi, Albrecht:

Regards!
-Qin
----- Original Message -----
From: Schwarz, Albrecht (Albrecht)<mailto:[email-masked]>
To: Qin Wu<mailto:[email-masked]> ; Kevin Gross<mailto:[email-masked]> ; xrblock<mailto:[email-masked]>
Sent: Monday, February 06, 2012 4:02 PM
Subject: RE: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

Hi,Albrecht:
----- Original Message -----
From: Schwarz, Albrecht (Albrecht)<mailto:[email-masked]>
To: Qin Wu<mailto:[email-masked]> ; Kevin Gross<mailto:[email-masked]> ; xrblock<mailto:[email-masked]>
Sent: Monday, February 06, 2012 12:50 PM
Subject: RE: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

Hello Qin:

---

From: Qin Wu <[email-masked]>
Date: Mon, 06 Feb 2012 19:20:15 +0800

Hi, Glen:
----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Shida Schubert" <[email-masked]>
Cc: "xrblock" <[email-masked]>
Sent: Friday, February 03, 2012 8:33 PM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

> applications."  An example or two might be nice here.

[Qin]: Okay, multimedia conferencing and VOIP applications can be regarded as two typical examples.
I will update the draft to reflect this.

> s/sampled,Interval/sampled, Interval/

[Qin]: Good Catch.

> Interval or Cumulative metrics" and "Sampled Value" etc.

[Qin]: Okay.

> MUST be set to zero by senders and SHOULD be ignored by receivers."

[Qin]: Agree.

> s%accumulation/encoding%accumulation/encoding%

[Qin]: Okay.

> s%decoding / playout%decoding/playout

[Qin]: Okay.

> who did and a new "Acknowledgments" section added.

[Qin]: Good suggestion. But I doubt I can identify anyone who really made textual
contributions from the other who didn't. I like to leave it as it does and keeping on
adding anybody who makes contributions or comments into this section.

---

From: Glen Zorn <[email-masked]>
Date: Mon, 06 Feb 2012 18:48:30 +0700

On 2/6/2012 6:20 PM, Qin Wu wrote:

...

> adding anybody who makes contributions or comments into this section.

In that case, II would suggest changing the title of the section to
"Acknowledgments".

...

---

From: Qin Wu <[email-masked]>
Date: Mon, 06 Feb 2012 19:53:13 +0800

----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "xrblock" <[email-masked]>
Sent: Monday, February 06, 2012 7:48 PM
Subject: Re: [xrblock] WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

> In that case, II would suggest changing the title of the section to

[Qin]: Looks good to me.

---

From: Glen Zorn <[email-masked]>
Date: Mon, 06 Feb 2012 18:58:44 +0700

> service(e.g., IPTV service, VOD service) are allowed?

I have no specification, but I have experience: whether "allowed" or
not, I regularly experience delays of > 1 second in streaming video.

> many extra bits are required to report such metric in the

What are specified or even acceptable are often different from reality;
since we are (i assume) measuring reality rather that abstract
specifications, I'm inclined to think that 1 second isn't enough.

...

---

From: Qin Wu <[email-masked]>
Date: Tue, 07 Feb 2012 11:37:20 +0800

Hi, all:
From the data I got from BBF specification TR-126:
I am aware that 
a.there are many Real-time, applications such as VoIP, gaming and streaming audio and video,
If the real time application is interactive, e.g., gaming, VOIP, the acceptable delay is << 1s
If the real time application is timely, e.g.,streaming audio and video, the acceptable delay is ~10 s. 

b.Also there are many other best effort internet application,e.g., web browsing, email, voice and video messaging,
these applications are all responsive, therefore the desirable delay is ~2 sec.
For detailed data, you can read G.1010.

As for end system delay, this delay includes jitter buffer delay. In the the case of IPTV service, Jitter buffer 
may take more than several seconds. Therefore I believe 16-bit metric in 1/2^16 units is not enough to report
the roudn trip delay or end system delay more than 1 s.

In order to fix this, I propose to change 16bit metric in 1/2^16 units to 24bit metric in 1/2^16 units. In this case,
the maximum value of roudn trip delay can reach 256 secs which is more than enough to report acceptable delay
for any real time application and other best effort internet application.

Any objection or other opinion?

Regards!
-Qin
----- Original Message ----- 
  From: Schwarz, Albrecht (Albrecht) 
  To: Qin Wu ; Kevin Gross ; xrblock 
  Sent: Monday, February 06, 2012 4:36 PM
  Subject: RE: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

  Hello Qin,

  BR,
  Albrecht

    Hi, Albrecht:

    Regards!
    -Qin
      ----- Original Message ----- 
      From: Schwarz, Albrecht (Albrecht) 
      To: Qin Wu ; Kevin Gross ; xrblock 
      Sent: Monday, February 06, 2012 4:02 PM
      Subject: RE: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

        Hi,Albrecht:
        ----- Original Message ----- 

          Hello Qin:

--------------------------------------------------------------------
            From: [email-masked] [mailto:[email-masked]] On Behalf Of Qin Wu
            Sent: Montag, 6. Februar 2012 03:46
            To: Kevin Gross; xrblock
            Subject: Re: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

            ----- Original Message ----- 
              From: Kevin Gross 
              To: xrblock

---

From: Qin Wu <[email-masked]>
Date: Tue, 07 Feb 2012 14:38:46 +0800

----- Original Message ----- 
From: "Glen Zorn" <[email-masked]>
To: "Qin Wu" <[email-masked]>
Cc: "Schwarz, Albrecht (Albrecht)" <[email-masked]>; "Kevin Gross" <[email-masked]>; "xrblock" <[email-masked]>
Sent: Monday, February 06, 2012 7:58 PM
Subject: Re: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay (Ending on Feb 3)

> not, I regularly experience delays of > 1 second in streaming video.

[Qin]: That's true. But we need to differentiate round trip delay from other
delay,e.g., channel changing latency which is one accumulation delay.
another example is IPTD is not round trip delay and defined as one way delay
between monitoring point at source and destination  (See section 6.2,Y.1540).

> specifications, I'm inclined to think that 1 second isn't enough.

[Qin]: Based on my observation, I agree.

---

From: Kevin Gross <[email-masked]>
Date: Wed, 8 Feb 2012 11:29:31 -0700

The draft says that the metrics are _typically_ derived from SR/RR. There
are more accurate means of measuring if you have another time reference
such as IEEE 1588 and use the 64-bit timestamps in the SR.

In IDMS work we did not identify a need for network forwarding statistics
with greater than 1/65536 s precision. Network performance varies enough
that there's probably not much usable information at higher resolution than
that.

I'm glad to see that we're able to accommodate RTT > 1 s with your most
recent proposal. With these changes, it appears to be technically adequate.

I would, however, recommend for mean, min and max RTT we use the same sort
32-bit field used in SRs. I just think a 24-bit field is difficult to
access and I'm not aware of any critical space constraints.

Kevin Gross
+1-303-447-0517
Media Network Consultant

2012/2/6 Qin Wu <[email-masked]>

> b.Also there are many other best effort internet application,e.g., web
> browsing, email, voice and video messaging,
> As for end system delay, this delay includes jitter buffer delay. In
> the the case of IPTV service, Jitter buffer
> In order to fix this, I propose to change 16bit metric in 1/2^16 units to
> 24bit metric in 1/2^16 units. In this case,
> *From:* Schwarz, Albrecht (Albrecht) <[email-masked]>
> *To:* Qin Wu <[email-masked]> ; Kevin Gross <[email-masked]> ;
> xrblock <[email-masked]>
> *Sent:* Monday, February 06, 2012 4:36 PM
> *Subject:* RE: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay
> (Ending on Feb 3)
>
> Hello Qin,
> instead of refering a particular service specification, I think that the
> justification is much simpler, just from MEASUREMENTS (similar as TEST)
> perspective:
>
> *The value range (and resolution) for MEASUREMENTS should be (at least
> one order) "better" than the communication SERVICE specification(s) with
> regards to considered performance metrics.*
>
> *From:* Qin Wu [mailto:[email-masked]]
> *Sent:* Montag, 6. Februar 2012 09:14
> *To:* Schwarz, Albrecht (Albrecht); Kevin Gross; xrblock
> *Subject:* Re: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay
> (Ending on Feb 3)
>
>  Hi, Albrecht:
> *From:* Schwarz, Albrecht (Albrecht) <[email-masked]>
> *To:* Qin Wu <[email-masked]> ; Kevin Gross <[email-masked]> ;
> xrblock <[email-masked]>
> *Sent:* Monday, February 06, 2012 4:02 PM
> *Subject:* RE: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay
> (Ending on Feb 3)
>
> You are appearently focusing on the category of CONVERSATIONAL services
> (like telephony, conferencing, telepresence, etc).
> However, looking at STREAMING services, you may find use cases where even
> multiples of seconds would be acceptable (particularily if unidirectional).
>
> *From:* Qin Wu [mailto:[email-masked]]
> *Sent:* Montag, 6. Februar 2012 07:20
> *To:* Schwarz, Albrecht (Albrecht); Kevin Gross; xrblock
> *Subject:* Re: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay
> (Ending on Feb 3)
>
>  Hi,Albrecht:
> *From:* Schwarz, Albrecht (Albrecht) <[email-masked]>
> *To:* Qin Wu <[email-masked]> ; Kevin Gross <[email-masked]> ;
> xrblock <[email-masked]>
> *Sent:* Monday, February 06, 2012 12:50 PM
> *Subject:* RE: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay
> (Ending on Feb 3)
>
> Hello Qin:
> 2nd Why is more than one second not acceptable, or more exactly: did you
> consider the plethora of possible application protocols (and services) over
> RTP? Even for conversational services ...
>
> [Qin]: I don't have a clear answer to what the range of unacceptable delay
> for real time application is. but when I read RFC4588, section 1, 2nd
> paragraph:
> "
> Also I am ware of that in ITU-T G.114, it is recommended that for VOIP
> application, a steady-state end-to-end delay of 150 ms as the upper
> That's why I assume the delay more than 1 second(i.e.,1000 milliseconds)
> is unacceptable. If I am wrong, please correct me.
>
> Regards,
> Albrecht
>
> *From:* [email-masked] [mailto:[email-masked]] *On
> Behalf Of *Qin Wu
> *Sent:* Montag, 6. Februar 2012 03:46
> *To:* Kevin Gross; xrblock
> *Subject:* Re: [xrblock] 答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay
> (Ending on Feb 3)
>
> *Sent:* Saturday, February 04, 2012 6:29 AM
> *Subject:* Re: [xrblock]答复: WGLC for draft-ietf-xrblock-rtcp-xr-delay
> (Ending on Feb 3)
>
> So the question is do we really need to report unacceptable latency that
> is more than 1 second? If the answer is yes, we can easily fix this